RSL10 Rebooting if disconnected from debug link


I am working on a RSL10 base demo app, i am using couple of things around the RSL10 and it is working “well”.

Right now i want to use the RSL10 without debug usb tool (JLINK), but only with the BLE communication but while connected to the ONSemi IDE it work perfect and do never have an issue like a “reboot”, when i do disconnect my board from the PC it remains working literally 140 seconds and then reboot and start again for 140secs again…

Though it was the Refresh Watch Dog function wasnt called, but it is.

Is something i am missing here? Sorry if this is a newbie mistake from my side!

Thanks in advance and greetings to the community!


Which application example are you using form our CMSIS pack?

How do you power your board while it is not connected to the USB see power options for V _ BAT or V regulated . Are you using our RSL10 board?

issue like a “reboot”,

How do you know that is " reboot" issue and not something else? Any prints screens from this event would help.

Hello @martin.bela

Thanks for your time,

I am using the ICS_Example, this is an example that uses BLE communication.

I do know the RSL10 is rebooting due to:

I do Keep the printf “Entering Main loop” outside the "while(true), only way it shows it to me again, is through a reboot, right? Also i have a “real time counter” register through the “previous_time” to count the time since RSL10 does initiate, and it goes only to 140sec and then reboot.

EDIT: Also, regarding the “reboot” issue, i have connected a Bluetooth terminal on an Android Device to connect to the RSL10, there i am also printing information same as through the JLINK, and after 140 seconds, the connection/pair does not work anymore and i have to connect/pair again.

Also, about the board, i have made a “custom” board based on the RSL10-SENSE-GEVK model.

And about the V_BAT and V Regulated, i have it connected both VDDO and VBAT to 3V3 from a regulator.


I look forward to hearing from you soon! And thanks in advance for your thoughts!



I have deleted my last post because i found a strange behaviour, first i have added couple of “Sys Watchdog Refresh” to my code in MainLoop and also, i have “deleted” all the “printf” statments that comes through the JLINK/RTT View.

Is there a buffer or something when using this such way of “printf” ?, without these, it works fine.

Greetings community.

1 Like


The printf utility makes use of our DMA (specifically channel 7) to copy the buffer contents into the UART interface while running in the background.

While the first call of this function is not blocking (ie. your firmware will keep running while the DMA pushes the buffer to the UART), and follow-up printf calls will wait for the previous UART transfer to be finished and for the DMA channel to be free.

If you seeing a watchdog reset only when printf is utilized, it is likely that the DMA is not being freed properly or that the print utility itself is locking up and the watchdog is triggering after 4s and then again after 8s causing a reset.

One way to start debugging why this is occurring is to setup the firmware to dump the UART and DMA register values into Flash or other non-volatile memory so that they can be analyzed after the reset occurs to check what state the interfaces are in prior to lock-up.