Flash-resident bootloader for i.MX RT1064

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Flash-resident bootloader for i.MX RT1064

3,268 Views
niranjan1
Contributor I

Hi,

I am trying to configure a flash-resident bootloader for a custom SoC based on i.MXRT1064. I didn't see the ota_bootloader example in the evkmimxrt1064 SDK, so I'm trying to port the ota_bootloader example from evkmimxrt1060. I have a few questions regarding the operation of the bootloader:

1) I only see a flashloader in the rt1064 examples. Is a flash-resident bootloader (ota_bootloader) in the works for this processor/evk? If not, is porting the ota_bootloader for rt1062 a good way to go about it?

2) I changed the flash address/size and the linker script in the ota_bootloader example for rt1062 to be compatible with rt1064. I was able to build and debug using a jlink debugger. Does this bootloader only support USB operation (I see a comment in bootloader_config.h "i.MX RT Series only supoort HS USB")? Currently, I have UART1 connected to the PC to act as a debug console and was hoping the bootloader operation can be tested with just the UART.

3) I am unable to see any output on the UART console when running the bootloader code. I have enabled required preprocessor directives and can see LPUART1 being initialized and debug_printf() trying to write to LPUART1, when debugging. Am I missing something or is it an issue with bootloader pin muxing? I can see the hello_world example print out to the console.

4) I see that the user application needs to populate a bootloader configuration table. The bootloader looks for it at an offset from APP_VECTOR_TABLE. If it is not populated, does the bootloader simply wait for input on USB/UART?

Thanks,

Niranjan

Labels (1)
0 Kudos
3 Replies

3,088 Views
jingpan
NXP TechSupport
NXP TechSupport

Hi Niranjan, 

1. yes, it's ok to port ota_bootloader from rt1062 to rt1064. You can read AN12290 which introduce how to migrate.

2,3. There is a known issue in project readme: Currently, this example can't be downloaded using Jlink, for no supported flash algorithm. I'm not sure if the issue is still there. You can use other debugger. The bootloader can support LPUART1 and USB. But it default support USB only. To enable LPUART1, you have to change the project from debug mode to release mode(properties->Settings->Manage Configurations-> active release mode). Then, in bootloader_config.h, add

    #define BL_TARGET_LPUART (1)

In peripherals_mimxrt1062.c, you can see which pins are mux to LPUART1.

4. Yes, the BCA is in APP_VECTOR_TABLE+0x3c0. When bootloader initialize, it is copied to RAM. You can see the detail in attachment. If there isn't BCA, it use default setting.

Regards,

Jing

0 Kudos

3,088 Views
niranjan1
Contributor I

Hi Jing,

Thanks for the response. I was able to get a part of the ota_bootloader working on the custom chip based on RT1064. I can load firmware through UART using blhost and can read/write memory and get properties,etc. When reliable update is disabled, the jump to user application happens when direct boot flag is enabled. The timeout feature didn't appear to work, but I need to test further.

However, the reliable update mechanism seems to be different than the documents. The ota_bootloader code checks for an image header when reliable update is enabled. This image header structure(shown below) is different from the bootloader configuration structure referenced in the documents. Also, the image header is placed at the start of the primary partition, above the user app interrupt vector table. Is there a separate tool that converts the user binary/hex file into an image that is compatible with the reliable update feature?

// Image header is platform specific
typedef struct
{
uint32_t tag;
uint32_t load_addr;
uint32_t image_type;
uint32_t image_size;
uint32_t algorithm;
// Note: considering the address alignment requirement on the vector table, take RT1060 for example, the vector
// table must be 1KB aligned
// the header_size can be set to 1KB in this case, and the actual image will follow the header
uint32_t header_size;
uint32_t image_version;
uint32_t reserved[1];
uint32_t checksum[32]; // Can be CRC checksum
uint32_t padding[];
} boot_image_header_t;

Thanks,

Niranjan

0 Kudos

3,088 Views
jingpan
NXP TechSupport
NXP TechSupport

Hi,

They are different things. Please the BCA structure definition in property.h.

Regards,

Jing

0 Kudos