Very strange, I have lots of nRF52x experience, but this one has me stumped.
Successfully updated our custom board/application from nRF5_SDK_15.0.0 to latest as indicated below:
FreeRTOS (from SDK)
Segger Embedded Studio (same issue on 4.12 / 4.18 / 4.50)
After migrating to SKD16, everything works very nicely. It is a reasonably complex application.
We use default flash_placement.xml from SDK16 example applications.
Application passes all of our testing. In Debug mode, NRF_LOG via RTT is active. This all operates fine.
Verified we have excess RAM available to the application. RAM_START=0x20002a98.
ret_code_t ret_code = sd_ble_enable(p_app_ram_start); returns a start value of 0x20002220 ... so we are good here.
To help me isolate the problem, I have erased my nRF52832 IC, and no longer are using our Bootloader.
Only the Softdevice and Application are being loaded via SES.
The last to do item was to re-enable our JLINK debug monitor. This is the ONLY change we are making to the application
We use the recommended method, as outlined in https://github.com/NordicPlayground/j-link-monitoring-mode-debugging. We use the 3 files as is unmodified.
We use the SDK16.0.0 branch, and our JLINK options are set to:
SetMonModeDebug = 1
SetMonModeVTableAddr = 0x26000
We execute NVIC_SetPriority(DebugMonitor_IRQn, _PRIO_SD_LOW); in our Logger task.
When we do this, our application does not startup up at all, and the SES Debugger shows us at address 0x00000000 ... see attached picture below [Crash.png]
Note also the messaging indicating: T-bit of XPSR is 0 but should be 1. Changed to 1.
To further isolate the problem, I commented out NVIC_SetPriority(DebugMonitor_IRQn, _PRIO_SD_LOW); ... but no change...
Very weird ... [DebugMon_Handler] is being compiled in, but not being executed.
... and all of this causes the SES to fail in loading the application. I am a bit stymied.
I tried setting early breakpoints in thumb_crt0.s ... but it would not hit any of the early breakpoints.
As a very last investigative step, I took the SDK 16.0.0 example application, and modified it to support JLINK_MONITOR ...
... after some tweaking ... works like a charm :}
Free beer to whoever can solve my problem :}
I believe there's a bug in the 6.62b j-link driver, at least we're having problems in NCS with it. You'll have to revert back to an older J-link driver version for now.I've seen the "T-bit of XPSR is 0 but should be 1" before, but I can't for the life of me remember the root cause, my best bet is a buggy J-link driver.
Well turns out it was easy to downgrade back to my prior 6.54c, and Segger made it effortless to revert the JLink firmware back to a version that was dated Jan 7 2019. I completely uninstalled 6.62b, and reboot my PC.
So now back to much older (early 2019) JLink DLL and JLink nRF52-DK firmware.
Unfortunately behavior was identical. Debugger shows its at at address 0x0.
If all I do is change JLink options
from SetMonModeDebug = 1 SetMonModeVTableAddr = 0x26000
to SetMonModeDebug = 0 SetMonModeVTableAddr = 0x26000
then my application works perfectly.
I had done an EraseAll operation on my chip. Is that different than a Chip Erase ?
The latter requires a new hex file ... is all I can tell as being different.
I inspected the memory contents at 0x26000 in both scenarios, and they are identical.
I have Segger 6.50a on the nRF52DK which is working. I suppose you checked there really is an interrupt vector present? DebugMon_Handler and not just 0
.word Reserved_09_IRQHandler /*Reserved */
.word Reserved_08_IRQHandler /*Reserved */
.word Reserved_07_IRQHandler /*Reserved */
.word Reserved_06_IRQHandler /*Reserved */
.word DebugMon_Handler <<<=== Here
.word Reserved_03_IRQHandler /*Reserved */
Yes, I presently sniffing around that area ...
_vectors: .word __stack_end__ .word Reset_Handler .word NMI_Handler .word HardFault_Handler .word MemoryManagement_Handler .word BusFault_Handler .word UsageFault_Handler .word 0 /*Reserved */ .word 0 /*Reserved */ .word 0 /*Reserved */ .word 0 /*Reserved */ .word SVC_Handler .word DebugMon_Handler .word 0 /*Reserved */ .word PendSV_Handler .word SysTick_Handler
/* External Interrupts */ .word POWER_CLOCK_IRQHandler .word RADIO_IRQHandler
and if I dump memory contents at 0x26000
0x26000 20010000 00026361 000263BD 000263BF 000263C1 000263C3 000263C5 00000000
0x26020 00000000 00000000 00000000 0004DBB5 0004D135 00000000 0004DBD9 000263CD
0x26040 0002A6A1 000263CF 0002FCCD 0002E3C1 0002EE3D 000263CF 0002C7E5 0002AE2D
DebugMon_Handler Is at 0x26034 = 0x0004D135
// The least-significant bit of each vector must be 1, indicating that the exception handler is Thumb code
// See http://infocenter.arm.com/help/topic/com.arm.doc.dui0553b/DUI0553.pdf
Cool ... me becoming more educated in coronaisolation :}