Hi
I need to develop bootloader with RT1170-EVKB.
My bootloader strategy is as follow.
1. boot from FlexSPI - QSPI
2. Run Application
3. Update new firmware from lpspi or lpuart by custom protocol(Not Serial Downloader).
-> Replace the firmware code from QSPI starting address to new one.
4. Reboot and new firmware code is boot.
I don't know this method is a relevant process or not.
If you have another good method, please let me know.
I will install just one QSPI Flash for boot device.
However I have some trouble in understanding ROM api.
I'm trying to test a example in my RT1170-EVKB.
When I run the program after build successfully, it abnormally stop.
Stop code location is as follow
status = ROM_FLEXSPI_NorFlash_GetConfig(FlexSpiInstance, &norConfig, &option);
status = ROM_FLEXSPI_NorFlash_Init(FlexSpiInstance, &norConfig);
I just build and run the example.
Please let me know what should I check.
Thank you.
Actually, I want to know how to update my new firmware to the board.
My plan is as follow,
1. Boot from QSPI Flash(Internal boot)
2. Run application
3. Download new application via SPI or UART from PC.
4. Call ROM API and update the firmware.
5. Reboot in internal boot mode by software.
Is this step right? <-- this is the 1st question.
The next question is about ROM API.
I had run the next example.
I executed the program in debug RAM mode by checking "Link application to RAM in the compiler properties (settings/MCU Linker/Managed Linker Script).
It was executed without error, no hang.
However, when I tried to it with unchecked state(means QSPI ROM boot),
the program was hang some location. It's very unstable.
The stopped code position is variable.
What is the problem, and what I should check ?
This is my second question.
Thank you
Hi @AntonyHan
Q1
Your firmware update plan looks logically sound.
Q2
It sounds like your application runs fine in RAM but encounters issues when executed from QSPI Flash. You can check the followings.
1. Flash Timing and Configuration:
• Ensure that the QSPI flash timing and configuration are correctly set up. If the flash is not correctly configured, it can cause the system to hang or behave unpredictably.
• Check the FlexSPI configuration settings in your project and compare them with the QSPI flash datasheet.
2. Cache and Prefetch Settings:
• Ensure that the cache and prefetch settings are correctly configured when running from QSPI. Incorrect cache settings can lead to instability.
3. Linker Script:
• Verify that the linker script is correctly set up for QSPI Flash. Ensure that all sections (text, data, bss, etc.) are placed correctly in the memory map.
4. ROM API Usage:
• When using the ROM API, ensure that it is not being called from XIP (Execute In Place) memory. ROM APIs might have restrictions on where they can be executed from.
Hope this will help you.
BR
Hang
Hi @AntonyHan
The FlexSPI driver uses three basic steps: first call get_config() to get the complete FlexSPI module configuration, then call init() to initialize the FlexSPI and access Flash to get the SFDP table information, and finally call the Flash operation function (such as erase()). Here is a simple example.
#define g_bootloaderTree (*(bootloader_api_entry_t **)0x0020001c)
flexspi_nor_config_t config;
serial_nor_config_option_t option;
option.option0.U = 0xC0000008; // QuadSPI NOR, Frequency: 133MHz
uint32_t instance = 0;
g_bootloaderTree->flexSpiNorDriver->get_config(instance, &config, &option);
g_bootloaderTree->flexSpiNorDriver->init(instance, &config);
g_bootloaderTree->flexSpiNorDriver->erase(instance, &config, 0x40000, 0x1000);
Hope this will help you.
BR
Hang