cc2650 lpm.c update from January 11th causes sensortag to crash repeatedly

[michaelsmith9]

Hi, The update to the cc26xx-cc13xx cpu files in commit number 707353f made changes to the lpm.c file in cpu/cc26xx-cc13xx. These changes have causes my chip to power cycle when powered on (i.e. the code that I had running fine on it no longer runs as expected). I reverted to commit 7b95309 and my code works fine, (as lpm.c has not been altered in that commit). The alterations to rf-core.c/.h ieee-mode.c and soc-rtc.c do not affect my code. I tried a simpler program with the updated lpm.c file, one that just responded to button pushes and that works fine with the new lpm.c file. But my current program does not and I think that is because I am making use of the RTC on the cc2650 in my current code. I narrowed down the source of the error to lines 275-281 in lpm.c - where the next event is scheduled by calling soc_rtc_schedule_one_shot(...). So I guess the issue is: is this change to lpm.c absolutely necessary? and has anyone else checked the latest lpm.c file and tried using it with an app that makes use of the RTC on the SensorTag? Thanks for any thoughts/assistance provided, Michael

[bkozak-scanimetrics]

Hello Michael,

Maybe I'm just very confused but It looks like you got your commit id wrong. Did you perhaps mean to refer to the changes in a63efe9?

[michaelsmith9]

Hi Billy,

Yup you're right there! I did mean ab63efe9. The main issue is the changes made to lpm.c before that commit. I've had a bit of a look into the crash and it seems that the chip will call lpm_drop() in contiki-main.c twice before it crashes. The second time, the call to ti_lib_prcm_sleep() in lpm_sleep() fails and causes the crash. I originally thought the crash might have been due to the rescheduling of the RTC CH1 on line 279 because my more complicated app uses the RTC and it crashes and a simpler app does not use the RTC and it is fine. However, at the time of the crash, the more complicated app hasn't done anything with the RTC except for getting the seconds value so I'm not sure that the problem is RTC. I've encountered this sort of problem before where the chip will crash when I am using a ti_lib function (that at the end of the day just writes/reads to a register) and usually it has been because of a power domain not being on or not being checked to being on or some other checks not being performed before the call.

[bkozak-scanimetrics]

Just looking at the code I think I can see a problem; can't say for sure that it's what's causing your troubles yet.

It would seem to me that it is entirely possible that

(soc_rtc_last_isr_time() + next_event * RTIMER_SECOND / CLOCK_SECOND) <= RTIMER_NOW();

This might be caused by next_event ending up as zero (or may have even wrapped below zero).

If this should happen, then you will have effectively scheduled your wake-up time to be at a point in the distant future. Then, if `max_pm == LPM_MODE_SLEEPthe watchdog will reset you provided that you have it enabled (ifmax_pm != LPM_MODE_SLEEP``` then you just stay asleep for a really long time).

Furthermore, even when everything works correctly, I don't see any reason why next_event would be guaranteed to occur before the watchdog timer expires (although I think there are normally etimers in the network stack which will always be set at less than the watchdog period).

If this is happening frequently for you then I am guessing that you've done something to make this more likely to happen (as this shouldn't be likely most of the time). For example you might have:

• registered an lpm module which take a really long time to perform its request_max_pm routine
• set an etimer (or ctimer) which expires at a very short time into the future in your application.

[g-oikonomou]

Just a wild thought: what RTC channel is your app using, Michael?

[michaelsmith9]

Billy: I think you might be onto something there with the scheduling of the next wakeup time. I've not registered any lpm modules aside from the ones Contiki has by default, but I can look into it to double check. I may have a timer that could be triggering a process quite soon into the future as my more complex code does have several processes running so that could well be the reason why it is crashing and my other code isn't. And I am definitely using the watchdog at the start of my code. George: I'm not using a specific channel in the RTC, just calling AONRTCSecGet() to get the current seconds to allow me to keep track of the time. I just thought I should mention that I was using the RTC because occasionally I've had issues with calling the cc26xxware functions. Unfortunately, I was a student developing code at an organisation over the summer and as I have finished the summer period I left the organisation yesterday so I no longer have access to the code I wrote, but I will contact the people I was working for to see if they can investigate what you've raised further. Thanks very much for the help so far though!

[bkozak-scanimetrics]

If @michaelsmith9's unnamed employers are paying attention, I would appreciate if you could check if #1531 fixes the issues you are having.

Thanks.