Custom board will not boot without Jlink debugger attached

[jrhaws]

I have been tracking this problem in this private ticket as well ((Missing Ticket)) since I thought the issues were related. I figured I should split it out since it appears that they may not be related after all.

I'm having issues getting my custom board with an NRF52832 to boot on power up. I can only get it to boot properly if I attach my Jlink debugger. I have searched high and low for answers to this problem to no avail. I've looked at all the following tickets:

 Zephyr project on a custom board wont' start up after removing debugger 

 nRF52832 application won't start without RTT console 

 Interesting Issue with board configuration - application wont start unless "kickstarted" by RTT or debugger. 

And even a few more that I can't find the links for again.

I've verified that my HFXO is good and my LFXO also looks good. I've also included the MCUboot bootloader, and it still will not start on boot. Only when I select "Attach debugger to Target" in VS Code does it decide it wants to start the application.

My same application and project configuration runs just fine on the NRF52 DK with an NRF52832, so I hesitate to think it is just a configuration thing.

What am I missing?

Thanks!

Jon

[jrhaws]

Here is the output of nrfjprog --readregs:

nrfjprog.exe --readregs
R0: 0x00000020
R1: 0x00000000
R2: 0x80000000
R3: 0x00000000
R4: 0x40000000
R5: 0x00000001
R6: 0x00000020
R7: 0x00000002
R8: 0x00000001
R9: 0xE000E100
R10: 0x00000000
R11: 0x00000000
R12: 0x00000001
SP: 0x20002F68
LR: 0x0000207F
PC: 0x00001732
xPSR: 0x61000000
MSP: 0x20002FC0
PSP: 0x20002F68
RAZ: 0x00000000
CFBP: 0x02000001
APSR: 0x60000000
EPSR: 0x01000000
IPSR: 0x00000000

[jrhaws]

Okay, I think I have this figured out, but it doesn't make sense to me why I had to enable the bootloader.

There were two parts to the solution, each of which individually DID NOT resolve my boot issues, but together they do.

1. I had to set CONFIG_BOARD_ENABLE_DCDC=n.  I was unable to set this directly in either my prj.conf or my board_defconfig because the compiler would error out saying this was an unknown option. I found that I could set this option if I created a Kconfig file in my board directory with this content:

config BOARD_ENABLE_DCDC
        bool "DCDC mode"
        select SOC_DCDC_NRF52X
        default n
        depends on BOARD_PRU_001697

Once this was in my board directory, I was able to change the CONFIG_BOARD_ENABLE_DCDC to what I wanted it to be, but because I defaulted it to no in my Kconfig, I did not need anything further.

2. I had to enable MCUboot and define a custom partition scheme.

CONFIG_BOOTLOADER_MCUBOOT=y will enable the MCUboot bootloader, then I added a pm_static.yml file to my project directory to define the partitions, since MCUboot enables the Partition Manager and no longer looks for partitions in the devicetree. My pm_static.yml looks like this:

app:
  address: 0x8000
  end_address: 0x43000
  region: flash_primary
  size: 0x3B000
storage:
  address: 0x7e000
  end_address: 0x80000
  region: flash_primary
  size: 0x2000
mcuboot:
  address: 0x0
  end_address: 0x8000
  placement:
    before:
    - mcuboot_primary
  region: flash_primary
  size: 0x8000
mcuboot_pad:
  address: 0x8000
  end_address: 0x8200
  placement:
    align:
      start: 0x1000
    before:
    - mcuboot_primary_app
  region: flash_primary
  size: 0x200
mcuboot_primary:
  address: 0x8000
  end_address: 0x43800
  orig_span: &id001
  - mcuboot_pad
  - app
  region: flash_primary
  sharers: 0x1
  size: 0x3B000
  span: *id001
mcuboot_primary_app:
  address: 0x8000
  end_address: 0x43000
  orig_span: &id002
  - app
  region: flash_primary
  size: 0x3B000
  span: *id002
mcuboot_secondary:
  address: 0x43000
  end_address: 0x7e000
  placement:
    after:
    - mcuboot_primary
    align:
      start: 0x1000
    align_next: 0x1000
  region: flash_primary
  share_size:
  - mcuboot_primary
  size: 0x3B000
mcuboot_primary_storage:
  address: 0x7f000
  end_address: 0x80000
  orig_span: &id003
  - storage
  region: flash_primary
  size: 0x2000
  span: *id003
sram_primary:
  address: 0x20000000
  end_address: 0x20010000
  region: sram_primary
  size: 0x10000

This shrinks the boot partition to be smaller than the default and enlarges the image partitions, plus reserves some at the end for static configuration data.

With BOTH of these changes in place, my board now boots properly all the time.

My biggest question now is WHY?  The DCDC change I get - my DCC pin is unconnected, so I should disable the internal regulator.  However, why do I have to have the bootloader enabled as well? When I build this same image for the dev kit (without the DCDC or MCUboot additions) it boots just fine and runs just fine. Why are these necessary for my board?

Thanks for the support!

Jon

[Simonr]

Hi

I was about to suggest disabling the DCDC config in your custom board, as this is required when you don't have the DCDC components for the nRF52 to operate correctly. If this is set to Y without having the DCDC components the nRF52 might end up in an undefined state.

As for the Bootloader config. Does your project have a bootloader implemented, or are what exactly are you trying to flash onto your custom board? It could be that just the application and storage addresses/regions must be set correctly like you have done in the MCUBoot. If you don't need or intend to use a bootloader you should be able to set this in a your projects partition manager without having to enable a bootloader as well.

Best regards,

Simon

[jrhaws]

Simon,

Thanks for the feedback. The DCDC setting makes sense. I had set it to Y at first because I misread the other solutions, so that is clear to me.

The bootloader is still puzzling though. I've attached my DTS that should define the partitions, but maybe I need to define them in pm_static.yml? If that is the case, why does the NRF52DK not require a pm_static.yml for it? Or maybe I'm setting the partitions wrong in my dts.

Note that in my dts, I have tried removing the mcuboot partition and putting slot0 at 0x0 and slot1 higher, maintaining a 4-8 kB storage partition at the end.

Thanks for the feedback!

pru_001697.dts 

[Simonr]

Hi

As far as we can tell, the partitions seem to be set correctly, but the MCUBoot partition is set to a different size than in our standard. I will forward this case to one of my colleagues more experienced with the MCUBoot than me, as I'll need to get a second opinion on what could cause this. Thank you for your patience! 

Best regards,

Simon