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

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

mtsunstrum — Fri, 03 Apr 2020 19:46:43 GMT

OK, thanks. I am giving it a mental break ... but hope to take a look at again next week.

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

leonwj — Thu, 02 Apr 2020 21:07:30 GMT

ok, I can't see details of the vector table entries in your previous posts but yes it would be good to get the exact hardfault. Once you have those post back if you still need additional insight.

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

mtsunstrum — Wed, 01 Apr 2020 21:50:55 GMT

Yes, see previous notes.

I hit the HardFault_Handler: in ses_startup_nrf52.s during a memory_set loop operation on .bss memory range. Screenshot image will show the loop operation.

I will have to look to get an exact hardfault error code, but looks to be invalid memory access (even though images show CPU registers appear to point to valid addresses)

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

leonwj — Wed, 01 Apr 2020 20:07:29 GMT

Right, so have you eyeballed the vector table entries for the DebugMon handlers to ensure that they are pointing to the correct addresses?

Additionally, what data does your hardfault handler provide regarding the exact nature of the fault?

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

mtsunstrum — Sat, 28 Mar 2020 00:02:16 GMT

I don't seem to need to do anything special with SES.

I simply click in the editor to set a breakpoint within thumb_crt0.s, then start the application, and it will start at the breakpoint.

Yes, it is very confusing. I have another simpler SES application that uses the latest SDK, and I have SetMonModeDebug=1 and that application runs perfectly fine.

It is only my main application that is exhibiting this problem.

But set SetMonModeDebug=0, and my main application runs perfectly fine.

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

hmolesworth — Fri, 27 Mar 2020 20:58:22 GMT

You probably know about this:

Startup Completion Point
Specifies the point in the program where startup is complete. Software breakpoints and debugIO will be enabled after this point has been reached.

The default is main(); how are you specifying the initial run to breakpoint? I think "Only with no breakpoints set" in Run To Control can an earlier breakpoint be set; with this I can single step through all the assembler with SetMonModeDebug=1

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

mtsunstrum — Fri, 27 Mar 2020 20:13:12 GMT

Getting more information ....

Previously, I indicated when I had set SetMonModeDebug = 1, that I could not hit a breakpoint set in _start: in thumb_crt0.s

But I found 2 ways where I could hit this breakpoint:

#1 Run application with SetMonModeDebug = 0, then stop, change setting to SetMonModeDebug = 1 and restart

#2 ... or power down device, and perform SES Debug->Go operation with setting already set for SetMonModeDebug = 1

So now I could single step onwards to see where some bad behavior may be occurring.

Voila, and I am always HardFault_Handler: in ses_startup_nrf52.s somewhere during memory_set operation on .bss memory range.

See thumb_crt0.s:325

How might this be happening ?

Keep in mind when I have SetMonModeDebug = 0, the same application works perfectly.

I put support ticket in Segger, but the politely declined to support this issue.

Up to 3 beer bounty now :}

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

haakonsh — Fri, 27 Mar 2020 10:06:37 GMT

There's no problem in using eraseall vs chiperase.

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

mtsunstrum — Fri, 27 Mar 2020 01:28:48 GMT

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

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

hmolesworth — Thu, 26 Mar 2020 20:54:12 GMT

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

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

hmolesworth — Thu, 26 Mar 2020 20:19:03 GMT

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.

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

mtsunstrum — Thu, 26 Mar 2020 19:55:27 GMT

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.

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

mtsunstrum — Thu, 26 Mar 2020 19:39:02 GMT

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.

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

mtsunstrum — Thu, 26 Mar 2020 19:29:49 GMT

Been a while since I have looked at startup code ...

_start is at 0x26200

Is there any other code that gets executed upon reset and/or JTAG startup ... ie. Reset_Handler ?

I could see if possible to set a breakpoint elsewhere, since upon JTAG startup, I cannot get it to break at _start.

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

mtsunstrum — Thu, 26 Mar 2020 19:22:23 GMT

Typo on my part ... DebugMon_Handler is at 0x26030 in vector table.

I have confirmed it contains a value pointing to the handler in the map file.

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

mtsunstrum — Thu, 26 Mar 2020 19:01:46 GMT

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

etc ....

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

actual DebugMon_Handler in map file is at 0x0004D134 … not sure why offset by 1.
But this seems to be normal for ARM-Cortex M4
… all the vectors have the same characteristic, even in my working applications

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

hmolesworth — Thu, 26 Mar 2020 18:17:28 GMT

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

_vectors:
  .word __stack_end__
  .word Reset_Handler
  .word NMI_Handler
  .word HardFault_Handler
  .word MemoryManagement_Handler
  .word BusFault_Handler
  .word UsageFault_Handler
  .word Reserved_09_IRQHandler      /*Reserved */
  .word Reserved_08_IRQHandler      /*Reserved */
  .word Reserved_07_IRQHandler      /*Reserved */
  .word Reserved_06_IRQHandler      /*Reserved */
  .word SVC_Handler
  .word DebugMon_Handler  <<<=== Here
  .word Reserved_03_IRQHandler      /*Reserved */
  .word PendSV_Handler
  .word SysTick_Handler

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

mtsunstrum — Thu, 26 Mar 2020 17:42:53 GMT

I inspected the memory contents at 0x26000 in both scenarios, and they are identical.

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

mtsunstrum — Thu, 26 Mar 2020 17:24:00 GMT

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.

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

mtsunstrum — Thu, 26 Mar 2020 16:59:58 GMT

OK, found the info in JLink document UM08001

Looks like via JLink Configuration app I can replace firmware.

I'll update my findings ...

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

mtsunstrum — Thu, 26 Mar 2020 16:52:46 GMT

Very strange indeed. I have a strong suspicion it is the updated JLink firmware loaded into the nRF52-DK ... maybe not so much the DLL version.

Reason being, is that on my previous notes, my SES was using JLink DLL version V6.54c ... but I had somehow/somewhere downloaded 6.62b, and it auto-updated the nRF-DK JLink firmware.

I can definitely step back to a previous JLink DLL version, but curious as to whether it will allow downgrading of the firmware loaded into the nRF52-DK. My previous post shows the version loaded in is V2 dated Jan 21 2020.

Anyone with knowledge / experience on downgrading the JLink firmware in a nRF52-DK ?

Obviously this is more of a Segger question ... but curious if anyone has gone thru a downgrading process.

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

haakonsh — Thu, 26 Mar 2020 09:40:46 GMT

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.

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

mtsunstrum — Thu, 26 Mar 2020 02:53:50 GMT

I might even see if I can revert my firmware in the DK, and my JLink DLL back to an older V6.20 ish ...

... pain in the butt .. but who knows.

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

mtsunstrum — Thu, 26 Mar 2020 02:52:43 GMT

Thanks again. I will take a look into that tomorrow.

With my JLINK DLL cleanups (see postings below), now it is not at 0x0 ... but it is on another planet at 0xEA6AAA2C

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

hmolesworth — Thu, 26 Mar 2020 02:34:57 GMT

Yes, the chip erase removes the MBR. So .. this is worrying:

  .word   PDM_IRQHandler
  .word   0                           /*Reserved */
  .word   0                           /*Reserved */
  .word   MWU_IRQHandler

These are not reserved vectors, but they track to address 0x00000000. I have the following in the diagnostics I wrote:

//  Text Name               V  ID Peripheral Description                                      Base Addr
//  ==================     == === ========== ================================================ =========================================================
   "PDM",               // 45  29 PDM        Pulse Density Modulation (Digital Microphone)    0x4001D000 PDM_IRQHandler
   "NVMC",              // 46  30 NVMC       Non-Volatile Memory Controller                   0x4001E000 0                         ; Reserved
   "PPI",               // 47  31 PPI        Programmable Peripheral Interconnect             0x4001F000 0                         ; Reserved
   "MWU",               // 48  32 MWU        Memory Watch Unit                                0x40020000 MWU_IRQHandler

Maybe these vectors need populating; I do thus:

 __WEAK void PDM_IRQHandler(void)       {NVIC_DisableIRQ(PDM_IRQn); NVIC_ClearPendingIRQ(PDM_IRQn); ExceptionVectors.Counters.IrqCount_PDM ++;} // 29 PDM  Pulse Density Modulation (Digital Microphone) 0x4001D000
__WEAK void Reserved30_IRQHandler(void) {NVIC_DisableIRQ(U30_IRQn); NVIC_ClearPendingIRQ(U30_IRQn); ExceptionVectors.Counters.IrqCount_NVMC++;} // 30 NVMC Non-Volatile Memory Controller                0x4001E000
__WEAK void Reserved31_IRQHandler(void) {NVIC_DisableIRQ(U31_IRQn); NVIC_ClearPendingIRQ(U31_IRQn); ExceptionVectors.Counters.IrqCount_PPI ++;} // 31 PPI  Programmable Peripheral Interconnect          0x4001F000
__WEAK void MWU_IRQHandler(void)        {NVIC_DisableIRQ(MWU_IRQn); NVIC_ClearPendingIRQ(MWU_IRQn); ExceptionVectors.Counters.IrqCount_MWU ++;} // 32 MWU  Memory Watch Unit                             0x40020000

I forget why the source does not specify the missing vectors - why are they reserved? They don't have specific enable/disable interrupt registers I see .. and I don't actually always add them:

.weak Reserved30_IRQHandler
.thumb_set Reserved30_IRQHandler, Dummy_Handler

.weak Reserved31_IRQHandler
.thumb_set Reserved31_IRQHandler, Dummy_Handler

  .word   PDM_IRQHandler
  .word   Reserved30_IRQHandler        /*Reserved */
  .word   Reserved31_IRQHandler        /*Reserved */
  .word   MWU_IRQHandler