Putting RSL10 into standby mode results in reset

Dear community,

I have a problem with the standby mode of RSL10. When I send the device in standby mode using the command BLE_Power_Mode_Enter(&standby_mode_env, POWER_MODE_STANDBY), it seems to go into standby mode, but after that, it does not continue executing code but rather resets and I do not understand why (it is difficult to debug because once it is in standby mode, I don’t have access to the board anymore). The most important code that I used is in attachment ( in which macro USE_X32K_RC is not defined). It also seems that the WAKEUP_IRQHandler is not executed (by analyzing syos trace messages). So maybe the code crashes before it goes into standby mode?

I used:
CMSIS PACK RSL10.3.5.285

community_code.c (3.6 KB)

Can you inspect the DIG_RESET_STATUS and ACS_RESET_STATUS registers to determine the cause of the reset?

It is possible that a watchdog timeout occurs after the device is put into Standby. By default the watchdog timer is around 4s. Try adding Sys_Watchdog_Refresh() at the start of your while(true) loop.


Dear Jamie,

Thank you for your answer! The DIG_RESET_STATUS = 0x1 and ACS_RESET_STATUS = 0x7f00 after the reset. Analyzing p64 of the RSL10 hardware reference manual, this seems the reset is because of a power on reset? Could it be that this happens because I wrongly set some parameters in the ACS register or BLE parameters?
I do a watchdog refresh every 2 seconds in another process (in parallel). But even by manually refreshing the watchdog just before going into standby mode does not solve the issue unfortunately. Neither the the modification from SYS_WAIT_FOR_EVENT to SYS_WAIT_FOR_INTERRUPT. (as a side note, what is the exact difference between SYS_WAIT_FOR_EVENT and SYS_WAIT_FOR_INTERRUPT)?

Greetings Jona,

Did you by chance clear the DIG_RESET_STATUS and ACS_RESET_STATUS registers before going into sleep mode? If not I suggest doing that and trying again as the reset indications could be left over from the initial power-on. You can clear the DIG_RESET_STATUS flags by writing 0xf0 to that register and the ACS_RESET_STATUS flags by writing 0x7f to that register.

SYS_WAIT_FOR_EVENT and SYS_WAIT_FOR_INTERRUPT use the ARM “wfe” and “wfi” instructions respectively. The ARM documentation gives the specific differences. I suggested SYS_WAIT_FOR_INTERRUPT because it looks like you’re expecting a Wakeup interrupt for your code to continue execution.

I just noticed something that might be the issue: right before the SYS_WAIT_FOR_EVENT instruction you’re calling GLOBAL_INT_RESTORE(). That’s likely restoring the interrupt enables to the settings when GLOBAL_INT_DISABLE() was last called, which is before the WAKEUP interrupt is enabled. Try instead using
to disable interrupts and
to enable them.

Hi Jamie,

Thanks for you advice. Now the registers are as follows: DIG_RESET_STATUS = 0x1 and ACS_RESET_STATUS = 0x800, which means that the reset seems to have occurred due to a VDDM reset (VDDM is supply voltage for memory functions). From the manual, I read that this can occur if the VDDM falls below a threshold. Would that because I don’t explicitly specify the trim value of the VDDM in low-power mode?

If instead of:
bool powerModeEnterd = BLE_Power_Mode_Enter(&standby_mode_env, POWER_MODE_STANDBY);,
I use:

/* Update wake-up configuration and control registers */
						WAKEUP_DIO3_DISABLE      |
                    	WAKEUP_DIO2_DISABLE      |
                    	WAKEUP_DIO1_DISABLE      |

	/* Update wake-up control and clear previous wake-up events */
	                	WAKEUP_DIO3_EVENT_CLEAR      |
                        WAKEUP_DIO2_EVENT_CLEAR      |
                        WAKEUP_DIO1_EVENT_CLEAR      |

Then a reset does not occur, and the codes resumes operation after a ‘wakeup due to the DIO0 pad’ (which is also strange as I disabled wakeup due to DIO0 pad). Regarding the timing information in syos_trace, the wake up occurs already ±24 ms after sending it in low-power mode (although I don’t know if this is reasonable to look at, as in standby mode, the timers might be disabled, so the board has no knowledge of time anymore?)

Using the __set_PRIMASK instead of GLOBAL_INT_* did not make a difference. In the sample code ‘peripheral_server_standby’ of RSL10, I see that they use also GLOBAL_INT_* before and after the low power mode.

The ‘peripheral_server_standby’ example goes in and out of standby with the following sequence:

        /* Mark the entry of power mode */

        BLE_Power_Mode_Enter(&standby_mode_env, POWER_MODE_STANDBY);

        /* Mark the exit of power mode */

So on the exit of BLE_Power_Mode_Enter() the system is back in the high power mode implying that the BLE_Power_Mode_Enter() routine performs the write that puts the system into low power mode along with the required power supply, clock, and memory management. Ultimately it seems that you want to use the BLE stack, so I’d suggest going back and using the configuration settings including calibration from the example.

Replacing the call to BLE_Power_Mode_Enter() with custom code without also removing the call that enables the BLE radio is probably not a good idea.

Sorry I’m just guessing here on some of this - I haven’t played with the board in a while myself!

It’s curious that in your code you have a line commented out because it causes the board to reset, and now you also have this indication of a VDDM issue. I tried your code starting at main() on the RSL10 EVB and it works fine. Are you using an RSL10 EVB or your own design? If an EVB, which one and what are the jumper options? There seems to be something odd with your power supply. Not sure that relates to your reset issue or not, but maybe it is.

Hi Jamie,

Thanks a lot for your help. I use the RSL10-SIP-001GEVB development board, with the jumper configuration as in the attached figure (different from the default configuration, I use a regulated external power supply instead of the USB as power supply). I use an external lab power supply with a voltage of 3.6V. Do you think this could pose an issue?


That looks to be the right setup unless there’s a really low current limit on the external supply. It would be a simple experiment though to put the power option jumper back to USB powered and see if you still have the issue.

Hi Jamie,
Unfortunately, that didn’t solve the problem, I still observe the system resets. I think the best way moving forward is to implement also the calibration of the voltages, as in the example provided by ON Semi, but then it is still strange that it works without calibration on your board but not on mine…

Let us know if that works.

If not, can you share all the hardware initialization code you’re using? You mentioned at one point you have another process running in parallel - does it manage any of the hardware?