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

[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.