• State Not Answered
  • Replies 34 replies
  • Subscribers 63 subscribers
  • Views 5769 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 246851
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

Parents
  • 0

    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. 








  • 0 in reply to haakonsh

    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.

Reply
  • 0 in reply to haakonsh

    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.

Children
  • 0 in reply to mtsunstrum

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

  • 0 in reply to mtsunstrum

    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

  • 0 in reply to hmolesworth

    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
  • 0 in reply to hmolesworth

    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.

  • 0 in reply to hmolesworth

    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.

Related

core_v2_widget.Hide()