Problem bringing up a custom board (cant see board outside of bootloader mode)

[hmahdi]

I have designed a custom board for the nrf52840 and upon testing it in the nrf connect sdk (using a JLink), I can only see the board when it's in bootloader mode. When it's in normal operation, the debugger does not show it. 

Additionally, it does not appear as a USB device although I enabled USB CDC. In fact, I kept the configuration pretty much similar to the nrf52840 dongle when I defined the custom board on the nrf connect sdk.

Has anyone run into a similar issue? Are there any guidelines for how to debug such a problem?

[Einar Thorsrud]

Hi,

I have designed a custom board for the nrf52840 and upon testing it in the nrf connect sdk (using a JLink), I can only see the board when it's in () mode. When it's in normal operation, the debugger does not show it. 

If the debugger is connected, then you should always see it. Can you explain a bit both how you test, how your firmware is and how your HW is.

Additionally, it does not appear as a USB device although I enabled USB CDC. In fact, I kept the configuration pretty much similar to the nrf52840 dongle when I defined the custom board on the nrf connect sdk.

Difficult to say here. Bu tif you are not even able to debug, there could be a more fundamental issue. I think you need to get the basics working first.

Could it for instance be that you have connected the debug (SWD) lines to a GPIO that you force high or low from your application? (that is just a wild guess, we need more information to make more precise suggestions).

[hmahdi]

Sorry for my late reply. I tried to get a GPIO to output a high but nothing is happening. I tried the same program on a dongle and it worked.

Here is the schematic of the custom board:

MCU_Schematic.pdf

[hmahdi]

That is what I thought, however, I also tried to use the ftsab-debugger configuration which starts at 

0x000000000 : 

&flash0 {
	partitions {
		compatible = "fixed-partitions";
		#address-cells = <1>;
		#size-cells = <1>;

		/* The size of this partition ensures that MCUBoot can be built
		 * with an RTT console, CDC ACM support, and w/o optimizations.
		 */
		boot_partition: partition@0 {
			label = "mcuboot";
			reg = <0x000000000 0x00012000>;
		};

		slot0_partition: partition@12000 {
			label = "image-0";
			reg = <0x00012000 0x000069000>;
		};
		slot1_partition: partition@7b000 {
			label = "image-1";
			reg = <0x0007b000 0x000069000>;
		};
		scratch_partition: partition@e4000 {
			label = "image-scratch";
			reg = <0x000e4000 0x00018000>;
		};
		storage_partition: partition@fc000 {
			label = "storage";
			reg = <0x000fc000 0x00004000>;
		};
	};
};

It did not change the behaviour. I made sure to remove BOARD_HAS_NRF5_BOOTLOADER

Sorry for asking too many questions but it's frustrating because I know the debugger sees the microcontroller but i am getting literally nothing. I dont think it's a hardware issue so most likely, it's the board configuration. 

[hmahdi]

I found this person saying the reset pin could solve the problem. I will try to connect the reset to the jlink:

https://devzone.nordicsemi.com/f/nordic-q-a/82547/cant-program-custom-board

I'll keep you posted. Meanwhile, if it seems anything is wrong with the configuration i posted please let me know!

[hmahdi]

Unfortunately, connecting the reset pin did not change the behaviour.

[Einar Thorsrud]

Hi,

Can you backtrack and continue to test with the Blinky example first, and use a board based on nrf452840dk_nrf52840 (not the dongle!)? Even if you have a dongle form factor, the nrf452840dk_nrf52840 is likely a better starting point as it has no fuzz. Then it should be enough to only change the LED pin to get the blinky sample working.

[hmahdi]

Thanks for your patience we me. I remade the board with the vscode extension this time (not starting from the dk or the dongle) to back track even more.

It seems this is definetly on the right track, because I no longer get a SIGTRAP when running debug (but of course I cant actually debug because jlink still only sees the board when the reset switch is flipped).

Here is a screenshot of when I run debug in reset mode: 

P.S. I did what you suggested by essentially only adding the one pin needed by the blinky program for the sake of simplicity.

[hmahdi]

I have some more information about the error. When I use the "recover board" feature in vscode, I can see the board when not in reset mode as long as I have not downloaded any code to the board. So what I did, I clicked debug on this clean board, and I got a new error message:

Program
 received signal SIGTRAP, Trace/breakpoint trap.
0xdeadbeee in ?? ()
Debug-14: Enqueuing {"command":"disassemble","arguments":{"memoryReference":"0xdeadbeee","offset":0,"instructionOffset":-200,"instructionCount":400,"resolveSymbols":true},"type":"request","seq":14}
Note: We detected the following memory regions as valid using gdb "info mem" and "objdump -h"
    This information is used to adjust bounds only when normal disassembly fails.
================================================================================
  Using following memory regions for disassembly
================================================================================
      Size   VMA Beg   VMA End   LMA Beg   LMA End  Attributes
================================================================================
  Unfortunately, No memory information from gdb (or gdb-server). Will try to manage without
  ------------------------------------------------------------------------------
  0000503c  00000000  0000503c  --------  --------  (.sec1) contents alloc load
================================================================================
Debug-14: Dequeuing...
Debug: Gdb command: -data-disassemble -s 0xdeadbbce -e 0xdeadc20e -- 5     1600 bytes 
Error: GDB failed: Cannot access memory at address 0xdeadbbce (from data-disassemble -s 0xdeadbbce -e 0xdeadc20e -- 5)

[Einar Thorsrud]

Hi,

I am sorry to say, but there is nothing here that rings any bells. Other than that I still struggle with this:

hmahdi said:

but of course I cant actually debug because jlink still only sees the board when the reset switch is flipped

If the reset pin is enabled and reset is asserted the device is in an undefined state, so nothing and anything could happen. So there is no point in operating in this condition (if that is what you mean).

[hmahdi]

I totally agree that it doesn’t make sense to operate in this mode and I know it won’t work. I was just trying to do it because the debugger won’t see the board otherwise. I know that is not the expected behaviour and the jlink should see it when it’s not in reset mode.

[Einar Thorsrud]

Which type of J-Link debugger are you using? And what VDD voltage to you measure when you hold the device in reset and what do you measure when it is not held in reset? Also, check voltage on SWDIO signals from the nRF?

I ask because if you have a basic J-Link which is fixed to be used with ~3.3V, then you will have problems before you can write to GPREGRET0 so that the high voltage regulator outputs a higher voltage (default is 1.8V).

[hmahdi]

I measured VDD in both normal and reset modes, and it was 3.3v

Additionally, the SWDIO is 3.3v 

I am using the JLink EDU Mini. Could that be why?