nRF5340 - UART boot mode selection

[Gabriele]

Hello,

I want to program nRF5340 via UART.

What is the hardware related event that puts the application processor in program mode over the UART ?

All ARM microprocessors I've worked with have special pins with "boot-mode" function.
When the device reset is deasserted, the boot mode selection is determined by the logic values of these pins.
I suppose nRF5340 does the same. Or not?

I'm in the hardware design process, and need to fix this.

Regards,
Gabriele

[Gabriele]

Thanks haakonsh,

Kconfig tells that BOOT_SERIAL_DETECT_PIN is "11" for BOARD_NRF52840_PCA10056.
In the HW schematics of PCA10056 the RESET pin is P0.18.
How does P0.18 relates to 11 ?

[haakonsh]

You're mixing two concepts here. The reset pin called nRESET is used to reset the MCU, in case of the nRF52840 this pin can be configured as a GPIO instead.

The BOOT_SERIAL_DETECT_PIN is used to signal the bootloader that you wish to start the DFU procedure.

[Gabriele]

Great.

In my application the user cannot put her hands on the board, to press buttons etc. Thus DFU must be entirely managed by SW.
This is the idea (look at the circuit)

a) the user sends a command like "please, DFU on next reboot"
b) the nRF5340 sets DFUEN high long enough to charge the capacitor, then resets the board
c) on reboot DFUBOOTn is found low, and the DFU process starts
d) during the DFU process, the capacitor discharges through the large resistor

[haakonsh]

If the ext MCU will send a UART command to the application then you can just store that state in persistent storage and issue a system reset, then check for that state in the bootloader. In that case, you won't need the BOOT_SERIAL_DETECT_PIN  signal at all. 

[Gabriele]

Good idea! I'll get rid of the circuit.

[Gabriele]

Sorry, one last question. So far we dealt with DFU handled by a custom FW.
What about the very first DFU ?
How do I do it ?

[haakonsh]

Are you asking about production programming? If so you need VDD, GND, SWDIO, and SWDCLK exposed to an SWD programmer interface. 

You need to program at least the bootloader and a DFU with the UART interface during production. 

An alternative is to create an SWD interface in the other MCU and use that to program the nRF device, this can serve as the future DFU process as well. Though I would not recommend it unless you've got large volume production as it is a fair bit of development involved. 

[Gabriele]

For production programming the SWD method would be fine.
On the PDK I see two different SWD interfaces

P18 (Debug In)
P19 (Debug Out)

I guess P18 is the one I have to replicate on my board.
Is it correct ?

A second question is about nRF5340 reset in relation to DFU.
I want to keep the BOOT_SERIAL_DETECT_PIN as a backup DFU mechanism.
For the BOOT_SERIAL_DETECT_PIN mechanism to work, is a Soft Reset equivalent to a Pin Reset ?

[haakonsh]

Gabriele said:

I guess P18 is the one I have to replicate on my board.
Is it correct ?

 Yes, you're correct.
 

Gabriele said:

For the BOOT_SERIAL_DETECT_PIN mechanism to work, is a Soft Reset equivalent to a Pin Reset ?

 For DFU purposes yes, as the bootloader is the first piece of code executed after a reset. A soft reset resets the CPU only, a pin reset resets the rest of the MCU as well.

[Gabriele]

Perfect,
that means I can throw away also this circuit.
Thanks

[haakonsh]

Well, I'd still connect the ext MCU to nRESET, it's a good last resort if the nRF53 locks up for a currently unknown issue, but you do not need R1 or Q1. nRESET has an internal 13k pull-up, so if you configure AL27/P0.24 as high impedance the nRF device will not reset, then you configure it as output low when you need to reset the nRF device. 

[Gabriele]

That's clear, for bootloader restart the Soft Reset is sufficient.
But if the nRF53 locks up for an unknown issue, it will not respond on the UART and then the user will be adviced to power cycle the system.
This is because the system comprises only the nRF53. There is no external MCU.