Strictly necessary cookies are on by default and cannot be turned off. Functional, Performance and Tracking/targeting/sharing cookies can be turned on below based on your preferences (this banner will remain available for you to accept cookies). You may change your cookie settings by deleting cookies from your browser. Then this banner will appear again. You can learn more details about cookies HERE.
Strictly necessary (always on)
Functional, Performance and Tracking/targeting/sharing (default off)
There are two separate blocks of code that are executed before the user’s code is executed after a reset. These blocks reside in ROM and in SFlash and are only executed by the ARM® Cortex®-M0+ CPU. The boot code in ROM cannot be changed and is programmed during the silicon manufacturing process. The section of SFlash that is used during the boot sequence is programmed during the test and calibration process. It is One Time Programmable (OTP) and remains valid even when the device is erased, just as ROM.
After reset the Cortex-M0+ CPU starts execution in ROM. It validates the trim data and boot code in SFlash with a Hash algorithm. If the data and code are valid, the trim data is used to calibrate hardware for basic CPU operations as well as calibration of analog blocks functions, such as bandgap trim, opamp offsets, etc. After the trim and calibration is complete, CPU execution jumps to the previously validated Flashboot code that is stored in SFlash.
Flashboot configures the debug port properly depending on the mode of operation such as normal or secure. The user has the option to permanently (OTP) set the level of debug access or to totally disable the debug port for a full secure environment. After the debug port has been configured (or disabled) the user’s program is optionally validated with a Hash function. Depending on the level of security required, the user’s code signature (output from the hash function) may be encrypted to validate that only code from a secure source may be executed.
After the user code has been validated, the Cortex-M0+CPU then starts to execute user code in main Flash. The programmer than decides when to enable the Cortex-M4 CPU. The timing of this is up to the developer. Validation of the Cortex-M4 code was validated at the same time the Cortex-M0+ code was validated, so there is no need to re-validate it. At this point, both CPUs (Cortex-M0+ and Cortex-M4) will be executing code. Interactions between the two CPUs can be with shared memory or with the IPC (Inter-Processor Communication) block. At least 8 IPC channels are provided for the developer to use as required.
Feel free to leave comments and ask questions, we appreciate the feedback!