nRF Connect for VS Code: code suddenly stopped executing. Build, flash, verify successful

[amandaheg]

Hello, 

I've been developing an nRF52840 on a custom PCB for ~1 month now, and my environment was working previously. After updating my version of Jlink and installing other python VS code extensions, code that was once building, flashing, and running successfully now will build, flash, and verify, but will never run. No RTT, uart serial, or GPIO are functioning on the board and I can't get any configuration or environment changes to fix the problem. 

I have gone back to attempting to build and run the blinky example (using a GPIO that I can easily measure on my board) so that I can get the code to run and execute main at all. 
When I do this, I still get the same successful building and flashing but the code seems to never reach main. 

I have noticed that under my build outputs, I see the following:



I have a project for another target that compiles & runs successfully, and i noticed that under main.c, the size (bss, text, and data) were much larger and none were 0. the size of zephyr.elf seems much more appropriate - but when I hit flash it flashes using the file merged.hex. 

I was wondering if anyone could shed light on why main.c would be so small (it seems like parts of zephyr or my program are not linking) and the difference between flashing zephyr.elf and merged.hex. 

relevant files: 

prj.conf: 


(at various points, I tried to also include logging, RTT, or uart - none of which changed the behavior)

custom_board.dts: (2 images)





main.c:




Build output: 


Flash output: 



The entire board is only pulling 8 mA, which is much too low for me to think that any code is executing on the nRF52840-QIAA. 

Thank you, let me know if anyone else has had a similar issue!

[Håkon Alseth]

Hi,

 

Q1: If you enter debug mode, is the firmware stuck somewhere?

Q2: Does your custom design have DCDC inductor in-place, and/or an external 32k oscillator in place?

 

If not, please add this to your overlay to disable DCDC:

&reg1 {
	regulator-initial-mode = <NRF5X_REG_MODE_LDO>;
};

and enable internal 32k RC oscillator:

CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y

 

Kind regards,

Håkon

[amandaheg]

Thank you so much for the response!

1) In debug mode, it does pause in reset.S in this function:

movs.n r0, #0

2) There is no DCDC inductor in place between DEC4 and DCC - DCC is floating and DEC 4 is connected to ground through a 1uF cap. There IS an external 32 MHz oscillator connected between XC1 and XC2

I just attempted a build where I added

&reg1 {
regulator-initial-mode = <NRF5X_REG_MODE_LDO>;
};

to the device overlay to disable the DC/DC converter and there was no difference in program operation or in the debug pause. 

Is there any way to verify that the regulator is actually being disabled in the build? And would that prevent my files from linking properly?

Thanks,
Amanda

[amandaheg]

Something else that might be of note - for the original project files (not the barebones led example I was attempting to run) my zephyr.map and zephyr_final.map are missing several libraries). It looks like lots of files aren't being linked - from timers, to log libraries, to clock libraries differing.

These are just a few screenshots of the diff between his working zephyr_final.map (left) and my failing projects' zephyr_final.map (right)

Our prj.conf should be exactly the same, we are using the same version of Zephyr (3.1.0 for SDK and toolchain) and the same main.c 

Apologies if I'm barking up the wrong tree here. 
Thanks,
Amanda

[Håkon Alseth]

Hi Amanda,

 

amandaheg said:

Something else that might be of note - for the original project files (not the barebones led example I was attempting to run) my zephyr.map and zephyr_final.map are missing several libraries). It looks like lots of files aren't being linked - from timers, to log libraries, to clock libraries differing.

Hard to state what differs, but the images show that one project has logging enabled, and the other seems to have it disabled.

 

amandaheg said:

1) In debug mode, it does pause in reset.S in this function:

movs.n r0, #0

This is highly likely the reset vector, ie. the starting point of the controller. Try running the target, then pausing, to see if it is stuck.

amandaheg said:

2) There is no DCDC inductor in place between DEC4 and DCC - DCC is floating and DEC 4 is connected to ground through a 1uF cap. There IS an external 32 MHz oscillator connected between XC1 and XC2

I just attempted a build where I added

&reg1 {
regulator-initial-mode = <NRF5X_REG_MODE_LDO>;
};

to the device overlay to disable the DC/DC converter and there was no difference in program operation or in the debug pause. 

Is there any way to verify that the regulator is actually being disabled in the build? And would that prevent my files from linking properly?

LDO mode must be enabled, since you have no DCDC inductors.

For the LFCLK (32.768 kHz), this is a separate clock as compared to the HFCLK (32 MHz).

HFCLK is required, while LFCLK is optional, as there is an internal 32.768 kHz RC oscillator option available.

 

If you do not have a external 32.768 kHz oscillator, then you need to set:

CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y

 

Kind regards,

Håkon

[amandaheg]

Thank you so much! 

Adding the clock control line resulted in code that runs! 

Thank you so much! 
Amanda

[amandaheg]

Just for my own understanding - do you have any idea as to why this setting could have been the fix, even though it wasn't included in any of my previous builds that did work? Is is set enabled by default and could something have inadvertently disabled the 32 KHz clock? 

thanks,
Amanda

[Håkon Alseth]

Hi Amanda,

 

Always happy to help out. Glad to hear it runs now!

amandaheg said:

Just for my own understanding - do you have any idea as to why this setting could have been the fix, even though it wasn't included in any of my previous builds that did work? Is is set enabled by default and could something have inadvertently disabled the 32 KHz clock? 

Usually, you will see this in the board file, more specifically the board myboardname_defconfig file. Here is an example for a nRF-based module that does not have external 32k:

https://github.com/nrfconnect/sdk-zephyr/blob/ncs-v3.1.1/boards/ezurio/bl652_dvk/bl652_dvk_defconfig#L22

 

Kind regards,

Håkon