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

[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 

[Hieu]

Jon,

I have been transferred this case and I will try to support you.

Regarding the pm_static.yml file, that file is optional, whether the Partition Manager is in used or not. If the Partition Manager is in used, pm_static.yml could be used to make a user-defined static partitioning scheme. More on this in the Partition Manager documentation: Partition Manager — nRF Connect SDK 2.4.1 documentation (nordicsemi.com).

Regarding partitioning using the .dts file, it only works when the Partition Manager is not enabled. If the Partition Manager is enabled, it will completely override any configurations in the DeviceTree. 

Unfortunately, the behavior where adding the bootloader makes the project work make no sense to me either. Much more often we receive support requests of the opposite issue...

To potentially get some idea on what could be wrong, could you please try the following setup:

• Do not add MCUboot, but add the Partition Manager to your project (CONFIG_PARTITION_MANAGER_ENABLED), see if things work

My only reasonable (self-evaluated) guess is that MCUboot configured some peripheral/clock/regulators in a way that helps the application runs.

In your initial report, you said that attaching the J-Link debugger let the device boot. I supposed this is more related to the resolved DCDC issue, but do you mean just the debugger being physically connected help? Or do you mean you are debugging?

Best regards,

Hieu

[jrhaws]

Hi Hieu,

Thanks for the support!

I'm learning more and more the more I continue testing. For example, I can run the radio_test example without MCUboot enabled, but every time I have tried my own application it will not run on its own unless MCUboot is enabled.

I will try as you suggest with the CONFIG_PARTITION_MANAGER_ENABLED setting and report back.

To answer your last question, when I say attaching the J-link debugger, what I mean is actually starting a debug session. Unless I start a session in VS Code, the code would not run. I don't have to flash the image, I just have to choose the "attach debugger to target" option.

Thanks!

Jon

[jrhaws]

We found our problem. It came down to the fact that we somehow failed to notice that we were missing a decoupling capacitor on DEC4, causing all sorts of noise and instability on the internal LDO. We added a cap to ground on that pin and now everything is working just fine.

My best guess as to why this started working when we enabled MCUboot was more due to disabling the DCDC, but that MCUboot allowed things to try and stabilize when it finally got to booting our image.

Thanks for the support!

Jon