CCS/CC1310: Stop watchdog before entering sleep mode

Hi TER

Sorry for late reply, I did not see your response until now.

When I enter sleep, I call this:

Semaphore_pend( semC_Main, BIOS_WAIT_FOREVER);

If I have initiated/started the WD, the application never starts again, as it does when I skip the WD init.

I have a bootloader running from 0x0000, and the application from 0x0000'1000.

As I see it, the application enters sleep, resets, and starts up in the bootloader, where it is stuck (I have not had the chance to find out if the bootloader actually is entered).

Even if I call the WD close function, this happens, so it MIGHT be that it is not the bootloader.

But I do not do anything than starting the WD, and then close it before entering sleep.

Any ideas why the application stops/resets?

Thanks Kaare

I only have one task, yes. And the current consumption indicates clearly that it is sleeping :)

Tried to run the ROV, but I'm not familiar with it, so I think I need a little help to what to do ?

br

Kaare

That would be possible, but it will take some time, and right now, I don't have a Launchpad board.

I have ordered a couple of them, but have not received them yet, and they will be used for another project the first week.

But I have tested some more, and tried to reset bu calling SysCtrlSystemReset(). For now, I only use the WD to reset the system, so I am happy if I can succeed to reset the application.

When calling this, the same thing happens: Debugger is cut off, and MCU seems to halt somewhere: Everything stops. Also if I have detached the debugger before trying to reset.

When I make a power cycle, the bootloader starts as expected, and jumps to application as expected.

So, everything works, but something is keeping the MCU from starting up from a software reset.

I seems like it is not a specific WD issue, but a software reset issue.

br

Kaare

Hello,

I'm interesting in this topic because I have a similar problem.

I have a project based on the Node-Concentrator example. The project of my "node" has 3 tasks:

• The first one (handler task) wakes up every 5 seconds and after the execution of some functions it generates an event which start a radio communication (radio task);
• The  radio task, which was waiting for the event from the handler task, sends a message to the "concentrator" and then waits for a reply;
• When a reply message is received or a timeout is detected, the third task, which was waiting on an event from the radio task, enetrs in execution and executes some functionalities. Then the micro goes to sleep again.

If I have understood well, the watchdog doen't work when the micro goes to sleep. So we have thought two ways to restart the board in case of problems:

• implement a timeout based on the clock driver which executes the SysCtrlSystemReset() function in case of expiration. The meaning of this is to avoid that something happens and the handler task is not executed anymore and the micro remains in sleep mode forever. The handler task restart the clock any cycle;
• this idea in our opinion could be not enough, so we would like to use the watchdog in order to restart in case of problems in the execution of our code, for example in a hardware ISR.

Everything seems working: the clock expires if I blocked the handler task on a while(1) cycle but also if I call the Task_sleep with a big timeout. If the handler task is blocked, the other task can't go in execution and this is verified.

My question is related to the watchdog. If I block the handler task on a while(1) cycle I can see the callback function of the watchdog working as waited. The same happens if I block an HW ISR.

The behaviour I don't understand is when I put the handler task on a big Task_sleep (bigger then the watchdog timeout): beeing all the task blocked on an event or on the Task_sleep, the micro is in sleep mode, so I think that the watchdog shouldn't count anymore. In this situation I see that the callback function of the watchdog is executed after the timeout. And if I configure the watchdog to restart, the board restart.

Please, can you explain the reason of this? And can you indicate me the mistake in may idea?

I hope my explanation is clear... thanks, Andrea.

Hi TER

I have used all day to try out different ways to make the reset/jump from Main application to Bootloader and back.
Played around using both SysCtrlSystemReset(), Watchdog reset and Jump to startadress.
SysCtrlSystemReset() was no success, but I did not test much on that.
Watchdog reset seems to be able to reset, and start bootloader, but then it dies during bootloading. I guess it is because Watchdog still runs during bootloader, even though the Watchdog did a RESET. Does the Watchdog keep running.

I have some success using JUMP to bootloader start address 0x0000:
asm(" MOV R0, #0x00000 ");
asm(" LDR R1, [R0, #0x4] ");
asm(" LDR SP, [R0, #0x0] ");
asm(" BX R1 ");

Using this to jump to Bootloader, it runs like this:
1. Copy new image to external FLASH
2. Jump to Bootloader / 0x0000
3. Bootloader flashes image
4. Jump to application / new image.
The above works perfect.

But if I let the system go into sleep (auto sleep after 5 minutes without user action), the jump to main application halts the MCU (or it looks like this):
1. Let application enter sleep mode
2. Copy new image to external FLASH
3. Jump to Bootloader / 0x0000
4. Bootloader flashes image
5. Jump to application / new image.
6. MCU HALTS -> Everything stops
________________________________
7. Powercycle
8. Bootloader checks if there is new firmware to flash
9. No new firmware -> Jump directly to main application.
10. Main application starts up with the new version, just FLASHED by the bootloader.
11. Repeat with new firmware, but before sleep mode, works fine.

The 10.000 dollar question: Why halts the execution when jumping to main application, first time after sleep mode?

I have no clue right now, what can make this happen, so if you have a clue where to search, I would be happy :)

Ps: Some of my struggling seems to be because the reset/jump is troublesome when the debugger hardware is connected, even though I am not debugging. All the above tests are done with debugger hardware disconnected.
Thanks
Kaare

Excuse me, I reply to my post because I suppose to have done a big problem... I thinkl that I've seen the restart caused by the watchdog just when I was in debug mode and the micro shouldn't go never in sleep in this condition.

Sorry again for my question... If you wanted to give me your opinion about my system restart I would appreciate it. We can't use an external watchdog becuase we have found just too expensive components or components not good about the consumption.

I have another question: is there the possibility to know the cause of previous reset of the CC1310? Like a register where it is possibile to read if the system is arriving from a power-on reset, from a watchdog reset or from a SysCtrlSystemReset reset?

Thanks again, Andrea