Hello,
I'm having issues with what I believe are interrupts, if I use the bootloader.
I'll give a brief description of the issue I faced, and then I'll state how to reproduce it with the built in examples.
# System Details
nRF5SDK Version: v16.0.0
Operating System: GNU/Linux (Arch Linux)
Compilation System: arm-none-eabi-gcc 10.2.0
No Softdevices
# My Issue
The actual issue I'm facing is:
When I run my application (which uses UART), without the bootloader (that is to say, it's flashed at 0x0), it works as expected.
If I flash the MBR, and a bootloader (I'm using the examples/dfu/open_bootloader one), and flash my application at 0x1000, then the application works until I initialise my UART and the corresponding module, at which point my program resets.
Having used the debugger, I can see I catch a SIGTRAP, and if I investigate the stack it can appear in different places, why this is I'm not sure.
Here's a snippet from the output of the debugger:
Program received signal SIGTRAP, Trace/breakpoint trap. 0x00000000 in ?? () (gdb) bt #0 0x00000000 in ?? () #1 <signal handler called> #2 0x00000000 in ?? () #3 <signal handler called> #4 0x00007150 in delay_machine_code () #5 0x000017ee in nrfx_coredep_delay_us (time_us=1000) at ./nRF5sdk//modules/nrfx/soc/nrfx_coredep.h:173 #6 nrfx_coredep_delay_us (time_us=1000) at ./nRF5sdk//modules/nrfx/soc/nrfx_coredep.h:136 #7 nrf_delay_ms (ms_time=<optimized out>) at ./nRF5sdk//components/libraries/delay/nrf_delay.h:72 #8 nrf_delay_ms (ms_time=50) at ./nRF5sdk//components/libraries/delay/nrf_delay.h:64 #9 init_uart () at ./modem.c:234 #10 _send_at (waitForURC=false, timeout=3000, obj=0x2003ebac, cmd=0x7058 "AT+CGMI\r\n") at ./modem.c:474 #11 0x000019b8 in send_at (timeout=3000, obj=0x0, cmd=0x7058 "AT+CGMI\r\n") at ./modem.c:524 #12 check_modem_power () at ./modem.c:68 #13 modem_power_on (model=model@entry=U201, ps=ps@entry=0x2003fff4) at ./modem.c:83 #14 0x0000133e in main () at ./main.c:76
I can't share my code, however I did manage to recreate the issue using an example which also uses an interrupt, the flash_fstorage example, which makes me think it's some issue with how interrupts are disabled/forwarded from the bootloader.
Are there some extra steps that must be done from the application if its loaded from the bootloader?
# Recreating the issue
1. Compile and flash the "flash_fstorage" example, for blank/armgcc, note it working as expected
2. Change the linker script, to place the program at 0x1000, rather than 0x0, as well change the length to something sensible so it doesn't overrun (0x14000 is plenty), and recompile (make sure to "make clean" first)
3. Flash the MBR (attached), open_bootloader, and the newly linked "flash_fstorage" example. Note how the program stops working, investigating with a debugger will provide something like
``` Program received signal SIGTRAP, Trace/breakpoint trap. 0x00000808 in ?? () (gdb) bt #0 0x00000808 in ?? () #1 <signal handler called> #2 0x00002f36 in drv_rtc_irq_trigger (p_instance=p_instance@entry=0x20000030 <m_rtc_inst>) at ../../../../../../components/toolchain/cmsis/include/core_cm4.h:1663 #3 0x00002bec in timer_request_proc_trigger () at ../../../../../../components/libraries/timer/app_timer2.c:510 #4 timer_req_schedule (p_timer=0x20000048 <cli_uart_timer_data>, type=TIMER_REQ_START) at ../../../../../../components/libraries/timer/app_timer2.c:510 #5 app_timer_start (p_timer=0x20000048 <cli_uart_timer_data>, timeout_ticks=<optimized out>, p_context=<optimized out>) at ../../../../../../components/libraries/timer/app_timer2.c:590 #6 0xfffffffe in ?? () ```
My key question is:
Should I be doing anything differntly in regards to interrupts, if my code has been jumped to from the bootloader, vs if its ran straight from 0x0
# Notes
* As you can see I suspect it's something to do with interrupts. The bootloader code does do some stuff with disabling/forwarding interrupts, but I don't know the detais of this system.
* The MBR is from the nRF5SDK for Thread, which from a post here on the forums was said to be a working MBR that doesn't expect a softdevice.
Thanks,
Joshua
