Watchdog Reset triggered after wakeup from power down mode in Eddystone

Hi Everyone,

I’m working on a project with RSL10. I’m trying to copy button functionalities of the Eddystone project that comes with the OnSemi IDE in my own project. The project comes with the UART selected per default in debugging trace configuration, with this configuration the RSL10 goes to power down mode correctly when I press the button for 3 seconds and when I push the button again the beacon directly wakes up, however when I disable the trace method, instead of UART I select disable, the beacon goes correctly to power down mode but when I push the button to wake it up, the program gets stuck somewhere for approximately 8,4 seconds (period of 2 watchdog timer duration) and then a watchdog reset is executed. I’ve been trying to find out why and where the program gets stuck with no avail.

I was wondering if this problem had already been detected and solved or if there is an updated version of the Eddystone project.

Please note that I’ve used the original Eddystone project, the only change I did was to disable the UART trace method.


To let me reproduce this issue on my side, could you please share more information for this?

  1. Which sample project you are using?
  2. Which EVB you are using?
  3. How to disable the UART in the code?



1 Like

Hi @larry.zhu,

Thank you for the response and the eventual help.

  1. The sample project: ble_broadcaster_eddystone.

  2. The board I use: RSL10 QFN EVB v1.3

  3. To disable the UART you need to set CFG_TRACE_TYPE to 0. You can find it in the app_config.h file.

Additional information that might be helpful:

The pin configuration is as follows:

#define SENSOR_ENABLE	4	/*Turn-On the Sensor*/
#define SENSOR_GND		5	/*Set the Ground for the Sensor*/
#define PIN_SCL         6	/*Clock Pin for I2C*/
#define PIN_SDA         7	/*Data Pin for I2C*/
#define PIN_UART_TX     4	/*Tx Pin for UART */
#define PIN_UART_RX     5	/*Rx Pin for UART*/
#define PIN_BUTTON      2	/*Button to power down and wake up the board*/
#define PIN_LED_GREEN   9	/*Green Led pin*/
#define PIN_LED_RED     11 	/*Red Led pin*/

I could see difference pin configuration as yours. (app_config.h).
I can see yours is not for RSL10 QFN EVB v1.3 since it does not have green and red led.
It only has one led.

You should select BOARD_RSL10_EVK.

You can see they have different PIN_BUTTON. one is DIO2 and another is DIO0.

1 Like

Hi @larry.zhu,

I failed to elaborate more on the board I’m using: For testing new features, that I plan to implement, I use this EVB, eventually the feature will be adapted to work in another board (a beacon with RSL10) with a different pin configuration, that’s why the pins in my case are different, this beacon is connected to the EVB via JTAG (P2 connector in EVBUM2529-D.pdf page 3). I highly doubt that the pin had anything to do with this issue.

I did as you suggested and chose the BOARD_RSL10_EVK. I connected a button to the DIO 0, and tested the project with UART Enabled and Disabled.

Since I can’t add more than one multimedia in one post, I will follow-up with the results, as a response to this post.


The results

As you can see in the results of tests, The same problem occurs as previously mentioned in my first publication.

  • With UART Enabled, the moment I press the button, the board wakes-up and starts advertising.

  • With the UART disabled, when I press the button to wake up the board, it takes apprx 8,4s.

In the documentation it is stated that the Watchdog Timer is set per default to apprx 4,2s. The first watchdog interrupt is always ignored, after a second watchdog interrupt the RSL10 does a reset. My assumption is this 8,4s delay, that we see, is the second watchdog reset being evoked, and since you can’t debug while in power down mode, I can’t properly assess the problem.


Could you please try this project on the RSL10-COIN-GEVB)? This sample is intended to run on that.
The BOARD_RSL10_EVK is not our RSL10 QFN EVB which you are using. (This QFN EVB does not have I2C sensor).


1 Like

Hi @larry.zhu,

thank you for the suggestion but unfortunately I don’t have any RSL10-COIN_GEVB at my disposal. is there anyway you could try the firmware on a RSL10_CON_GEVB and see if the problem reproduces or not ?