Hi Abner,
My response to AT+CEREG? is: +CEREG: 5,1,“8C33”,“0A282A39”,9,0,0,“00100010”,“00111000”
That means that T3324 and PSM are turned on, right? My active period is 2 minutes, but for testing, I’m sending a message every 30 seconds. If the response from the server does not come within the RRC connected period of ~6 seconds after a message is sent, then it won’t arrive until the next message is sent 30 seconds after the previous one.
Hi WizIO,
Here are some specific examples of problems that sometimes happen (keep in mind, nothing is consistent and most things work fine most of the time).
I have a callback function for the QIRD command that does some tasks and then sends an OS message to another task. Sometimes, when this message is sent and the callback function returns, the program then switches to the other task, prints a debug statement and then tries to take a mutex Ql_OS_TakeMutex(s_iUniversalMutex,0xFFFFFFFF). It crashes immediately. Other times, after the second task has successfully finished processing the message and it returns the the beginning of the loop and calls Ql_OS_GetMessage(&msg) again to wait for the next message, it crashes and restarts immediately.
There’s another spot in the middle of a function that sometimes crashes. I print a value with a debug statement (so I know it’s ‘1’), then I get and print the current task priority and remaining stack size. Then I have an if statement based on the value that is ‘1’ followed by a debug print. It sometimes crashes before the final debug print (sometimes it will make it one or two lines farther than this and then crash, or even crash in the middle of printing a debug statement).
APP_DEBUG("lat long valid: %d\r\n", jtracker_response.ref_ll_valid);
APP_DEBUG("ephem bitstream size: %d\r\n", jtracker_response.ephemeris_bitstream_size);
//sometimes crashes here
int iRet = 0;
iRet = Ql_OS_GetCurrenTaskLeftStackSize();
APP_DEBUG("\r\n<--Task[interpret response]: Task Remain Stack Size =%d-->\r\n", iRet);
iRet = Ql_OS_GetCurrentTaskPriority();
APP_DEBUG("\r\n<--Task[interpret response]: priority=%d-->\r\n", iRet);
//sometimes crashes here
if (jtracker_response.ref_ll_valid) {
APP_DEBUG("new lat/long is: ");
//sometimes crashes here
APP_DEBUG("%f, %f\r\n",
jtracker_response.ref_lat,
jtracker_response.ref_lng);
//sometimes crashes here
jedi200_dev->get_point_parameters.ref_latitude = jtracker_response.ref_lat;
jedi200_dev->get_point_parameters.ref_longitude = jtracker_response.ref_lng;
APP_DEBUG("new lat/long is: %f, %f\r\n",
jedi200_dev->get_point_parameters.ref_latitude,
jedi200_dev->get_point_parameters.ref_longitude);
}
lat long valid: 1
ephem bitstream size: 0
<–Task[interpret response]: Task Remain Stack Size =4408–>
<–Task[interpret response]: priority=4–>
F1: 0000 0000
V0: 0000 0000 [0001]
00: 0006 000C
01: 0000 0000
U0: 0000 0001 [0000]
T0: 0000 00B4
Leaving the BROM
Sometimes it will only get part way through printing a debug statement about sending a message and then crash soon after. Here’s an example where it fails to print the full message it is sending and then restarts soon after:
<–Send AT:AT+QISENDEX=0,118,"BFF7D
OK
, ret = 0 -->
done with statemachine, count: 1
F1: 0000 0000
V0: 0000 0000 [0001]
00: 0006 000C
01: 0000 0000
U0: 0000 0001 [0000]
T0: 0000 00B4
Leaving the BROM
Sometimes, on restart, my custom tasks don’t start (each are supposed to print a debug statement as their first line). There’s no crash here, it just doesn’t run.
Sometimes it can’t connect to the network, but never throws an error. It just sits there trying forever. After a manual reset, it usually connects within 10 seconds.
If it makes it past the first 5 or 6 loops (30 seconds each), then it will run forever with no crashes.
The patterns are the same, as far as I can tell, between my custom pcb and the BC66 eval board.
How can I get more information about these crashes? Is there any way to get errors printed out? How can I change task priorities? Is it possible the version 10 firmware file I have is corrupted?
Thanks,
Ben