Scheduler + UART. Function getting optimized out?

[Jared]

Hey All,

I'm using the nrf_drv_uart UARTE driver (NRF52832) communicating with an external device. The UART init code is executed using a function (call all_main in this instance) that is called by the scheduler to update the state of the app, initialize and de-init peripherals etc. I get to the point of initializing the UART in my code, compile, run it I get logs and it responds to reset requests (using jlinkexe). But, if I add a write and then a read the program compiles, the bootloader boots but the app does not launch. When using GDB in this state, it doesn't stop at the breakpoint at main. I don't see any GPIOs changing state.

So my fears are that the SD is asserting for some reason or that the particular function I'm calling is getting optimized out. 

I'm going to look into it more but I figure I would post my issue here to see if anyone else has had something similar.

Thanks

Jared

[Vidar Berg]

Hello,

I suspect the problem is in the bootloader since you are not reaching main in the app. I would suggest  to try the debug version of the bootloader which  has debug logging over RTT enabled by default, then check the log to see if there are any error messages. Alternatively, try the app without the bootloader present and see if you get the same result. 

Note: if you are programming a new app image with a programmer you also need to manually update the bootloader settings page so that the CRC check in nrf_dfu_app_is_valid() doesn't fail. 

[Jared]

Hey Vidar,

I think I managed to get past the issue. I definitely have still been seeing this off and on using the same setup. The more I've been using it the more I'm thinking it's some type of intermittent hardware problem. Sometimes the board doesn't boot at all, sometimes it boots but no RTT. It sometimes responds to reset commands (though that may be attributed to the tight main loop I'm running). Do note that when things stop working, it's not because I'm fiddling with the bootloader but rather making small changes to the main application (setting gpios, etc)

Have you guys seen any issues like this? I'm running on a newer MBP 15". The only other thing I could think of is it's the software on my machine that is causing the problems when flashing and running RTT. At this point I'm about to lose my sanity because the board works sometimes and doesn't other times. 

Thanks for the help!

[Jared]

I did, for sanity, take a completely different dev-board (PCA10056) and try a very simple example. Code is the same from this: devzone.nordicsemi.com/.../rtt-on-sdk-14-2-and-segger

Still no RTT output.

Looks like it's more of a Segger issue at this point. Version 6.30e Have you guys seen this at all Vidar Berg?

[Vidar Berg]

Hi Jared,

Are you developing with pure GCC, or with Segger embedded studio? Code changes may lead to code asserts, which by default, triggers a SW reset, see SDK error module. These kind of errors may be easier to catch if you can step through the code (with GDB or in an IDE). However, this doesn't explain why there is no RTT output. Could you try the ble_app_uart example and see if you get RTT output in the debug terminal (\examples\ble_peripheral\ble_app_uart\pca10056\s140\ses)?

Note: all BLE examples have support for RTT logging, just change NRF_LOG_BACKEND_RTT_ENABLED to '1' and NRF_LOG_BACKEND_UART_ENABLED to '0' in sdk_config.h before re-building the example. 

[Jared]

I'm using GCC only. I'm using the secure bootloader example along with a BLE example and UART0 on a NRF53832.

I did get the RTT to come over my console.. this time.I have noticed if I put my machine to sleep, I don't get anything over RTT until I re-flash the device. Even if I close JLinkExe and JlinkRTTClient and re-open them.

I noticed that my code (using the scheduler) continues to run in the background even if there is no RTT (LEDs turn on, UART traffic, responds to button presses). I did enable both DEBUG on both projects to see if I can catch the error by stepping through.