A small project I worked on was to understand how RT1050 boot-up performs from different memory types. I used the LED_blinky code from the SDK as a baseline, and ran some tests on the EVKB board. The data I gathered is described below, as well as more detailed testing procedures.
Testing Procedure
The boot-up time will be defined as the time from which the processor first receives power, to when it executes the first line of code from the main() function.
Time was measured using an oscilloscope (Tektronix TDS 2014) between the rising edge of the POR_B* signal to the following two points:
- FlexSPI_CS asserted (first read of the FlexSPI by the ROM)**
- GPIO Toggle in application code (signals beginning of code execution).***
*The POR_B signal was available to scope through header J26-1
**The FlexSPI_CS signal is available through a small pull-up resistor on the board, R356. A small wire was soldered alongside this resistor, and was probed on the oscilloscope.
***The GPIO pin that was used was the same one that connected to USER_LED (Active low). This pin could be scoped through header J22-5.
TP 2, 3, 4, and 5 are used to ground the probe of the oscilloscope. This was all done in the EVKB evaluation board.
Here are a couple of noteworthy points about the test ran:
- This report mostly emphasizes the time between the rise of the POR_B signal, and the first line of execution of code. However, there is a time between when power is first provided to the board and the POR_B system goes up. This is a matter of power electronics and can vary depending on the user application and design. Because of this, this report will not place a huge emphasis on this.
- The first actual lines of code of the application is actually configuring several pins of the processor. Only after these pins are executed, does the GPIO toggle low and the time is taken on the oscilloscope. However, these lines of configuration code are executed so rapidly, that the time is ignored for the test.
Clock Configurations
The bootable image was flashed to the RT1050 in all three cases. Afterwards, in MCUXpresso, the debugger was configured with “Attach Only” set to true. A debug session was then launched, and after the processor finished executing code, it was paused and the register values were read according to the RT1050 Reference Manual, chapter 18, CCM Block Diagram.
Boot Configuration: | Core Clock (MHz) * | FlexSPI Clock (MHz) | SEMC Clock (MHz) |
FlexSPI | 130 | 99 | |
SDRAM | 396 | 130 | 99 |
SRAM | 396 | 130 | 99 |
*The Core Clock speed was also verified by configuring clko1 as an output with the clock speed divided by 8. This frequency was measured using an oscilloscope and verified to be 396 MHz.
Results
The time to chip select pin represents the moment when the first flash read happens from the RT1050 processor. The time to GPIO output represents the boot-up time.
As expected, XiP Hyperflash boots faster than other memories. SRAM and SDRAM memories must copy to executable memory before executing which will take more time and therefore boot slower.
In the sections below, a more thorough explanation is provided of how these tests were ran and why Hyperflash XiP is expected to be the fastest.
Hyperflash XiP Boot Up
Below is an outline of the steps of what we expect the Hyperflash XiP boot-up process to look like:
- Power On Reset (J26-1)
- Begin access to Flash memory (FlexSPI_SS0)
- Execute in place in flash (XiP)
- First line of code is exectuted (USER_LED)
In MCUXpresso, the map file showed the following:
The oscilloscope image is below:
SDRAM Boot Up
The processor will bootup from ROM, which will be told to copy an application image from the serial NOR flash memory to SDRAM (serial NOR flash uses Hyperflash communication). The RT flashloader tool will let me load up the application to the flash to be configured to copy over memory to the SDRAM and execute to it.
It is expected that copying to SDRAM will be slower than executing in place from Hyperflash since an entire copying action must take place.
The SDRAM boot-up process looks like the following:
- Power On Reset (J26-1)
- Begin access to Flash memory (FlexSPI_SS0)
- Copy code to SDRAM
- Execute in place in SDRAM (FlexSPI_SS0)
- First line of code is executed (USER_LED)
In MCUXpresso, the map file showed the following:
In order to run this test, I followed these instructions: https://community.nxp.com/docs/DOC-340655.
SRAM Boot Up
For SRAM, a similar process to that of SDRAM is expected. The processor will first boot from internal ROM, and then go to Hyperflash. It will then copy over everything from Hyperflash to internal SRAM DTC memory and then execute from there.
The SRAM Boot Up Process follows as such:
- Power On Reset (J26-1)
- Begin access to Flash memory (FlexSPI_SS0)
- Copy code to SRAM
- Execute in place in SRAM (FlexSPI_SS0)
- First line of code is executed (USER_LED)
In MCUXpresso, the map file showed the following:
This document was generated from the following discussion: javascript:;
