Hello,
I have a problem that looks a bit like
devzone.nordicsemi.com/.../nrf52840-custom-board-won-t-boot-without-debugger-reset
For me, to be more precise:
nRF52840 custom board won't even reach mcuboot's main() without debugger "kick" start
but it will start on a DK PCA10056 (nRF rev3)
Context :
tests done on
target with a 32Mhz quartz and no 32.768Khz quartz, uses P0.0 and P0.1 as a serial port.
tests also done on
DK_1 : Modified DK for tests of my FW (PCA10056)
Modifed to match as much as possible my target
Disconnected the 32.768Khz quartz,
My FW uses P0.0 and P0.1 as a serial port
Re routed P0.0 and P0.1 toward the USB CDC pass through so that I can debug by USB the serial messages
FW is Using mcumgr for bootloader
Compiled with nRFConnect SDK v2.1.0
cpu on target : NRF52840_xxAA_REV2 ( I am sure that this is my target and not the nRF of the DK_2, that DK_2 has a rev3 )
cpu in DK_1 : NRF52840_xxAA_REV3
On the DK_1, my firmware works like a charm.
DK_2 : Another DK, unmodified.
My setup for testing on the target, is to use P20 of DK_2 to connect to the SWD of my target.
Reset pin of the nRF on the target is not connected to the DK_2. (GPIO from another CPU, that I can put also in HZ, but that does not help)
If I start a debug session on my target using P20 of DK_2, everything is fine :
flash of the target, breakpoint just before do_boot, run to continue.
Even after stopping the debugger and switching it off, the target continues ok. And, now the most strange : I can even reset my target, and it will restart OK.
However, if I switch off my target and switch it on, even if I reset (push button) it after, I will not properly start.
I can tell that it does not even reach the main() of mcuboot. (I did put some uart_poll_out() commands everywhere to check ) [yes, I have checked that uart_poll_out works when I can boot]
So, it seems that the nRF is locked in the very first phases. We even think that the 32Mhz clock is not running.
Same problem if I just flash the board and reset it.
The other person that had a similar problem found that by triggering the watchdog in case of a power on reset that would solve his problem
My problem is that I don't even reach the mcuboot code... so I can do nothing.
Could that have something to do with an errata of Rev 2 ?
Is there anywhere, in the config a place to precise the revision of my CPU, so that the correct workarounds are compiled ?
I have already spend 2 weeks on that...
Laurent
