How to upload an application via Flashloader?

[p_shep]

So still having troubles, but getting further...

For Ref: Using SDK 2.9.1, on the RT1064

So got Flashloader up and running, enumerates on USB, and the Secure Provisioning Tool can talk to it.

All fine.

Now, I've got the led blinky demo, shuffled it up to 0x70020000 (also moved the corresponding Flashloader BL_APP_VECTOR_TABLE_ADDRESS to the same), and removed the XIP headers.

Upload the demo app via the secure provisioning tool, and it'll merrily over-write the Flashloader's vector table at 0x70001000, keeping the code up at 0x70020000.

Now the blinky demo is working perfectly and the flashloader has been obliterated.

So I guess the SPT is being clever and making the image 'bootable', but i don't want it bootable, just 'as-is'.

I've tried MCU Boot Utility (v3.1.1) but it doesn't recognise the VID/PID

So how do I get my app to where I want it?

Thanks.

[p_shep]

Another separate but related thing:

If BL_FEATURE_HAS_FLEXSPI_NOR_ROMAPI is set, get_flexspinor_instance() returns an invalid value for the internal ROM API.

g_bootloaderTree->flexSpiNorDriver->get_config() succeeds with 1 as the instance, not 2.

[p_shep]

I'm just throwing everything into this thread now...

On the topic of the ROM API... what's the trade-offs between using it, and using the code on Flashloader?

[p_shep]

So many questions...

So how does the Flashloader code section get copied into RAM to run?

I generate the build, and everything it located in RAM in the linker. There's no mention of the flash address anywhere. I use the Secure provisioning tool to load it to flash. It does so at 0x70000000, but the vectortable reset handler, at 0x70002004 points to a RAM address: 0x200024A1.

I assume then the the ROM code copies the code from flash to RAM? But what tell it to do that?

[p_shep]

__WEAK status_t target_load_bootloader_config_area(bootloader_configuration_data_t *config)
{
    return kStatus_Fail;
}

So the BCA is not used on flashloader? OR are we supposed to add a function to read it?

There are several references to the configurationData in the flashloader code, so are we supposed to roll our own reader of the config area? Or This is just legacy stuff, not used anymore?

[gusarambula]

Hello p_shep,

The following Application Note explains the Flashloader (AN12238) with a bit more detail so it may help.

https://www.nxp.com/docs/en/nxp/application-notes/AN12238.pdf

This Application Note is focused on the i.MX1050 but the main concepts and how the flashloader works remains the same for the i.MX1064. The Flashlaoder package for the i.MX1064 can be found on the following link:

https://www.nxp.com/webapp/sps/download/license.jsp?colCode=FLASHLOADER-RT1064-1.0

As for the Bootloader Configuration Area (BCA), the i.MXRT ROM does not use this BCA format. Instead the image needs an Image Vector Table (IVT) to provide information to the ROM for booting.

I hope that this information helps!

Regards,
Gustavo

[p_shep]

Hi Gustavo,

Thanks for the reply. That application note is not one I've come across yet.

As to the BCA, In order to get everything to work, I had to implement the BCA area on the application (using the old kinesis tool to generate the table), then implement the above mentioned function populate the *config area from in flash.

The sticking point was in bl_main.c:

bool is_direct_boot(void)
{
bootloader_configuration_data_t *configurationData =
&g_bootloaderContext.propertyInterface->store->configurationData;

return (~configurationData->bootFlags) & kBootFlag_DirectBoot;
}

As the configurationData structure is populated with 0xFF on init, return is always 0, and we don't jump to application.

On the upload side, I took the script generated by the Secure Provisioning Tool and remove the two instructions which write the configuration block, and run that.

That finally got the application uploading and running.