RTT Logging is causing lags and WDT Resets

[Dave_couling]

I have a freeRTOS based system and my Logging Thread, which is based on the examples has odd behviour when used in conjunction with the WDT.   When I first program the board, the RTT Logging seems to lag, causing the WDT to not re-feed.  Causing a System Reset.   Why would the Segger RTT cause the system to halt for a few seconds upon the first programming?  After the reset, the System runs fine.  Obviously this is just for debugging, but need to verify it not a symptom of another underlying issue.

[Vidar Berg]

Hello,

The RTT backend shouldn't become blocking unless you have selected the 'BLOCK' mode in your configuration settings:

Could you please check that you don't have this mode selected? I can't think of any other obvious reasons for why logging is preventing the WDT from being fed.

[Dave_couling]

I've made sure that I'm not using Blocking mode in my sdk_config.h.  But still the WDT module won't feed.  I've tried placing the WDT feed in a task with a higher priorty than the Logging thread, but its still getting blocked.  Which means its happening in the backend module somehow.

Oddly its only an issue after each programming, but if I restart the debug from the IDE is runs fine.  Could it be a JLink driver issue?

[Vidar Berg]

Thanks for confirming. I have a few more follow up questions if you don't mind:

1. Have you tried to extend the WD timeout to more than a few seconds to see if the program only hangs temporarily?

2. Do you get the same behavior if you select the UART backend?

3. How are you viewing the RTT logs, in SES or RTTViewer?

[Dave_couling]

1.  Yes it still hangs

2.  Yes same behavior with the UART backend

3.  Using Putty

[Dave_couling]

I've traced this down to a vTaskDelay which is not returning the first time you run the code after programming.  If I reset the the chip on the IDE and run again everything it fine.  I was using SDK 17.0.2.  I reverted back to SDK 16.0 which I've test before and everything works fine.  So this seems to be related to SDK 17.0.2 and its freeRTOS library

[Dave_couling]

Looks like a similar error to this: https://devzone.nordicsemi.com/f/nordic-q-a/63998/freertos-wdt-sdk17-problem

Is there a plan to fix this issue in a new SDK?  

I removed the following line in nrf_drv_clock_init() from nrf_drv_clock.c which seems to fix the issue.

// if (nrf_wdt_started())
// {
// m_clock_cb.lfclk_on = true;
// }

[Vidar Berg]

Thanks for the update. Yes, the behavior makes sense if you are encountering this bug. We are planning to fix it!