RTOS/CC1310: What's the difference between lpm_shutdown() and SysCtrlSystemReset()

Hello Richard,

I am aware of that. I expect the same result of both of them. The SysCtrlSystemReset() is simply a command to do a reset while lpm_shutdown() is doing a controlled shutdown of power domains etc.In addition the source to leave the shutdown mode is configured. Once the io pin detects the configured edge it triggers a reset on mcu. It seems that there is some magic behind that "resets the mcu". I had to find this out when doing the following:

1.) Reset the mcu by SysCtrlSystemReset() several times and let run the application on mcu again
2.) Reset the mcu by lpm_shutdown() and let run the application again, then
--> trying again lpm_shutdown() doesn't work
--> trying a SysCtrlSystemReset() doesn't work

In the end I just would like to know what I have to do manually when doing a lpm_shutdown() to get the same result SysCtrlSystemReset() is doing.

Markus

Hello again,

Since last weeks state of knowledge I tried to understand the lpm functions, with the help of a launchpad cc1310 button example. Here the right button press simply goes to shutdown mode. Another button press then starts from lpm_shutdown again. From printf output I can see that the arm is resetting its application correct. This way of setting it to shutdown mode and wake up (respectively resetting then arm) works over and over again.
The difference between this example and my project is that the example does not have any shutdown_handler to shutdown any hardware while mine configures several io-pins to lowest power loss. Furthermore we use an I2C-eeprom where another shutdown_handler is registered in lpm. The arm is waiting on a dc power supply (while still supplied by battery) to wake up again.
I already reduced the peripheral uses by deactivating all i2c functions, making sure that the eeprom isn't causing any side effect. I am working on this quite hard problem for about four weeks now. Does nobody have any suggestions what to do?


Kind regards
Markus

Does that mean your main issue is too high current consumption in Standby?

Hello TER,

this is correct. We need to reduce the consumption to several microamps, but up to now even with the lpm_shutdown done and estimated being there there is about 800 uA current flowing. I desoldered some peripheral making sure they cannot take any current. I guess the lpm_shutdown is not doing what it should?

Markus

It could sound like you haven't managed to put the chip in standby. Have you closed all drivers before trying to go into shutdown? It could sound like one or more power domains still are on and can't be turned off before whatever is dependent on that power domain is turned off.

I thought this is done by lpm_shutdown  as the documentation is enumerating it  at http://www.ti.com/lit/ug/swcu117h/swcu117h.pdf#page=427. 

Btw, I assume you have the debugger disconnected when you are trying to put the device in shutdown?

Have you tried with the UART disconnected and/ or remove all UART from the code? If that works, do you have a UART_close() before trying shutdown?

UART is using its own shutdown_handler, waiting for switching off everything up to all serial data send out of Buffer. I expected that if in case of launchpad example it works it should do exactly the same for my module. To be honest I didn't take away the wires from module. I will do now. Do you expect any power supply from those lines that interact with the arm?

I checked it without uart lines connected. Nope! Doesn't work :(

You write that the UART has it's own power down sequence. Does that mean that you are not using the UART driver? I assume you are using TI-RTOS?

I am using Contiki with TI-RTOS as its basis. As I can see the functions to shutdown the uart are those from TI-RTOS.
More or less I took as basis the cc26xx-demo. I didn't change anything of the UART code of it. The more I searched for the problem with LPM the more I found out on all those functions. In the end the lpm registers like
LPM_MODULE(uart_module, NULL, lpm_drop_handler, NULL, LPM_DOMAIN_NONE);
As you can see the lpm_drop_handler function of cc26xx-uart.c is used. I don't know if this procedure is correct, but in a lot of your documentation there is "use the TI functions". So I do... Is it possible that there is some "magic" code between shutdown_mode and arm reset that might have an influence on the reset behaviour? I still do not understand why a call of SysCrtlSystemReset() all the time works perfect but lpm_shutdown() doesn't.

Hello TER,

Yes I tried this. This didn't work. I changed my strategy and try to reduce the power now by hard switching off power supply from hardware.