J-Link Device ROM bootloader

This article describes the special attention and potential pitfalls built-in ROM bootloaders of devices (MCUs, ...) can come with.

General

Nowadays, many if not the majority of the MCUs come with a ROM bootloader that is executed by the chip, before control is given to the user application and the actual user application is started. These ROM bootloaders have a variety of jobs, depending on what is needed for the actual MCU:

• Check different boot sources (internal flash, external QSPI flash, external NAND flash, ...), so where to start the user application from
• Make sure that the device is the state that is described as "reset state" in the technical reference manual of the device
• Make sure that all peripheral registers contain the so-called "reset values" described in the manual
• Evaluate the option bytes of the device and potentially open the debug interface, boot from a different source, setup flash partitioning, ... depending on the option bytes values
• Calibrate internal oscillators or peripherals of the chip

RAM debug

A common concept by many customers is: "Let's debug our application in RAM, until development is done and then move it to flash"
However, with a device implementing a ROM bootloader, this is no longer as easy as it sounds.
Imagine the following case:

• No valid application in any boot source
• ROM bootloader will stop booting at some point and remain in some kind of endless loop etc. in the boot ROM
• Debugger session is started and application is downloaded into RAM
• Debugger sets program counter and stack pointer to start of downloaded application

The developer will write the application in a way that it relies on what is called "reset state" or "reset values" described in the manual of the chip.
However, as the ROM bootloader did not find any valid application and stopped booting, it may also not have initialized or calibrated the peripheral clocks / registers / peripherals itself / ...
So the application now relies on a state the device simply is not in.
Possible effects range from none, over "Ethernet / USB / ... works unstable" up to random crashes of the chip.
These problems that are very time consuming to identify and usually they cannot be solved without having something "bootable"
in any of the boot sources the ROM bootloader checks, therefore making sure that the ROM bootloader boots through and fully initializes the chip.

So while debugging applications in RAM may work for simple applications that only toggle some PIOs / LEDs,
usually as soon as it gets more complex and peripherals like USB / ETH / ... are involved, things are more or less guaranteed to fail / work unstable.

Solution: When debugging in RAM is an absolute must have, then at least some valid boot header etc. should be programmed into flash once, to make sure that the ROM bootloader boots through and fully initializes the chip so that the values from the chip manual are matching the state the chip really is in.