The microcontroller by default boots to a known address in ROM like a standard microcontroller. However to get the microcontroller to work with the flash they use a hand off process. The boot ROM needs help understanding the flash chip. By default it boots up in compatibility mode them moves to the configured operating mode. The purpose of the boot2 is to determine the configuration mode. Once this happens the microcontroller can jump to the main application on flash.
The boot ROM will setup just enough hardware to make sure the USB boot loader in boot ROM works correctly. It will look for a boot2 record on the flash and process it if found. Once processing is complete it will attempt to run the entry point of the application which is a standard ARM reset vector if I recall correctly. Currently the hardware configuration used by the boot ROM is minimal and will not likely conflict with this entry point. However the flash configuration must persist.
Documentation of the dependencies for moving into main are not well documented. The work flow is also not documented well. The reset work flow is documented at a hardware level. It works mostly the same as the boot process. A different code path in the boot ROM is invoked. There is some communication passed between the application in flash and the boot ROM through hardware registers. (The SDK works this out for you.)
CMake and the SDK hide this entire process. VSCode using CMake plugin makes the entire process clean. (Programming is still manual but that's like using a USB drive.) For CMake: https://github.com/daveythacher/RP2040_SKELETON
Edit:
Core 1 is parked in the boot ROM using a special process. SDK can call it out of this process. The reset flow will take it back to the special process.
The boot ROM will setup just enough hardware to make sure the USB boot loader in boot ROM works correctly. It will look for a boot2 record on the flash and process it if found. Once processing is complete it will attempt to run the entry point of the application which is a standard ARM reset vector if I recall correctly. Currently the hardware configuration used by the boot ROM is minimal and will not likely conflict with this entry point. However the flash configuration must persist.
Documentation of the dependencies for moving into main are not well documented. The work flow is also not documented well. The reset work flow is documented at a hardware level. It works mostly the same as the boot process. A different code path in the boot ROM is invoked. There is some communication passed between the application in flash and the boot ROM through hardware registers. (The SDK works this out for you.)
CMake and the SDK hide this entire process. VSCode using CMake plugin makes the entire process clean. (Programming is still manual but that's like using a USB drive.) For CMake: https://github.com/daveythacher/RP2040_SKELETON
Edit:
Core 1 is parked in the boot ROM using a special process. SDK can call it out of this process. The reset flow will take it back to the special process.
Statistics: Posted by dthacher — Sat May 18, 2024 8:30 pm