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. 

[Jared]

Paying more attention closely to the logs, the device sometimes does lock up. When I re-flash and connect no RTT.

J-Link>g
J-Link>r
Reset delay: 0 ms
Reset type NORMAL: Resets core & peripherals via SYSRESETREQ & VECTRESET bit.
Reset: Halt core after reset via DEMCR.VC_CORERESET.
Reset: Reset device via AIRCR.SYSRESETREQ.
J-Link>g
J-Link>
****** Error: Communication timed out: Requested 12 bytes, received 0 bytes !
make: *** [debug] Interrupt: 2

This is the command I'm using to start my RTT session:

JLinkExe -device NRF52832_XXAA -speed 4000 -if SWD -SelectEmuBySN $(PROG_SER) -autoconnect 1

[Jared]

Seems like the only way for me to get it back in a working state is to unplug everything, put my computer to sleep, start JLinkEXE + RTTClient, full erase the chip, program my code back. Let me know if it's useful to post some logs, etc.

[Jared]

As I'm trying to reproduce the issue it may be around using the nrfjprog command while the RTT session is open. I haven't had an issue up until recently using this workflow. 

I set up the RTT connection using JLinkEXE and JLinkRTTClient, then while still open I'm developing I'm doing the occasional:

nrfjprog -s $(PROG_SER) -f nrf52 -e
nrfjprog -s $(PROG_SER) -f nrf52 --program $(OUTPUT_DIRECTORY)/$(TARGET_NAME).combined.hex --sectorerase
nrfjprog -s $(PROG_SER) -f nrf52 --reset

This is correlated with my `make flash` command. I really only run it after I've done my checks and made changes to be tested.

[Vidar Berg]

I haven't been able to reproduce this on my side yet. I used a MacBook Air with Jlink v.6.30e installed and the pre-compiled bootloader hex file from SDK 14.2.0.

Do you see this consistently with mentioned workflow, or is it still intermittent? 

[Jared]

Hi Vidar Berg

It's not as consistent as it was before. I think it was because of a tight main loop. As I've built out the code and the main loop as increased significantly I haven't seen the issue nearly as much. I did get some pointers from Rigado about re-flashing the J-Link on the development board itself but it didn't make much of a difference.

For other people who may have a similar issue: we're using the scheduler and basically queuing a "main loop" after every run. We have a state machine inside that main loop that changes the state of the app. When that loop is very small (little to no operations) it could very well lead to unexpected behavior. I remember having to physically time hitting the reset pin while trying to reset the chip when I "accidentally" programmed the chip with an unintentional blocking loop in the main function.