Scheduler + UART. Function getting optimized out?

RE: Scheduler + UART. Function getting optimized out?

Vidar Berg — Wed, 14 Mar 2018 12:31:54 GMT

The log buffer is typically processed in the main loop if you have deferred logging enabled:

// Enter main loop.
for (;;)
{
if (NRF_LOG_PROCESS() == false)
{
power_manage();
}
}

Is it possible that the changes you made caused the process function to be called more often, or reduced the amount of log messages? Wondering if this issue could be attributed to buffer overrun. You could try to increase the log buffer size in sdk_config to see if that helps.

Buffer configuration:

NRF_LOG_MSGPOOL_ELEMENT_SIZE

NRF_LOG_MSGPOOL_ELEMENT_COUNT

RE: Scheduler + UART. Function getting optimized out?

Jared — Tue, 13 Mar 2018 17:13:25 GMT

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.

RE: Scheduler + UART. Function getting optimized out?

Vidar Berg — Thu, 01 Mar 2018 07:23:14 GMT

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?

RE: Scheduler + UART. Function getting optimized out?

Jared — Wed, 28 Feb 2018 20:23:11 GMT

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.

RE: Scheduler + UART. Function getting optimized out?

Jared — Tue, 27 Feb 2018 21:48:13 GMT

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.

RE: Scheduler + UART. Function getting optimized out?

Jared — Tue, 27 Feb 2018 20:01:05 GMT

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

RE: Scheduler + UART. Function getting optimized out?

Jared — Tue, 27 Feb 2018 18:19:07 GMT

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.

RE: Scheduler + UART. Function getting optimized out?

Vidar Berg — Tue, 27 Feb 2018 14:14:23 GMT

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.

RE: Scheduler + UART. Function getting optimized out?

Jared — Tue, 27 Feb 2018 04:54:49 GMT

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?

RE: Scheduler + UART. Function getting optimized out?

Jared — Tue, 27 Feb 2018 04:30:31 GMT

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!

RE: Scheduler + UART. Function getting optimized out?

Vidar Berg — Mon, 19 Feb 2018 13:43:22 GMT

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.