Stable application crashes at address 0x00000000 when I add JLINK_MONITOR_ISR_SES.s but DebugMonitor_IRQn is disabled

[mtsunstrum]

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:

Setups:

SDK: nRF5_SDK_16.0.0_98a08e2

SoftDevice: 

FreeRTOS (from SDK)

Segger Embedded Studio (same issue on 4.12 / 4.18 / 4.50)

Windows 10

Custom board

---

Preprocessor definitions: 

BOARD_CUSTOM

NRF52

NRF52832_XXAA

NRF52_PAN_74

S132

SOFTDEVICE_PRESENT

NRF_SD_BLE_API_VERSION=7

CONFIG_NFCT_PINS_AS_GPIOS

FLOAT_ABI_HARD

INITIALIZE_USER_SECTIONS

NO_VTOR_CONFIG

ARM_MATH_CM4

FREERTOS

---

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 :}

[haakonsh]

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. 

[mtsunstrum]

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.

[mtsunstrum]

Coming from 15.0.0 sounds like MBR is new ... but I haven't familiarized myself with it.

Whats the easiest way to confirm that I have erased it ?

I see in the softdevice directory there is mbr_nrf52_2.4.1_mbr.hex  which looks to consist of a significant amount of code presumably.

Maybe my next step is to actually confirm that is truly erased, and not somehow getting in the way.

[mtsunstrum]

OK, I see MBR is at Flash address 0x0 and indeed I have MBR contents there that match contents of mbr_nrf52_2.4.1_mbr.hex, at least there 1st 100 bytes or so ...

I wonder if I have no Bootloader ... then if there is any reason for the weird interactions with JLink ?

But that doesn't make sense ... if I go back to my demo application running ble_app_hrs_freertos_pca10040, and modified to support JLink Debug Monitor, that works fine.

It also has no Bootloader, and same MBR programmed, using same SDK.

So bloody weird ...

----------------------------------------

But to isolate MBR as being a factor, would you know steps to erase it, and have it boot to application appropriately ?

I presume JLink may issue a reset command via JTAG after flash programming ... maybe that is the reason for that odd "T-bit of XPSR is 0 but should be 1" ... possibly MBR and JLink battling over something.

[hmolesworth]

I use the depreciated nRFGo Studio to Erase All. There is indeed an erase all in SES but I can't confirm that removes the MBR as I haven't tried it. nRFGo Studio is a good option. Nordic say use nRF Connect which should also work.

[hmolesworth]

// 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

[mtsunstrum]

Cool ... me becoming more educated in coronaisolation :}