Flashloader project for Adesto EcoXIP problem.

[jackking]

Hello,

I am trying to use the NXP Secure Provisioning Tool v2.1 to upload an XIP application to an Embedded Artists i.MX RT1062 board which uses the Adesto EcoXIP (ATXP032) for Flash.

Using MCUXpresso (and J-Link debugger) the application uploads and runs fine.
Switching to Secure Provisioning Tool (or NXP MCUBootUtility) the application uploads, but cannot execute.

I am using the flashloader that comes with Secure Provisioning Tool and I have also tried using a custom flashloader.bin based on the MCUboot SDK example in MCUXpresso SDK 2.8.6

I used MCUBootUtility to read out the flash memory (from location 0x60000000) to compare the two binary images.

There are some substantial differences between the two methods.
Specifically, the Flash Device Config Block (which starts at 0x60000000) is different.  Then the IVT, Boot Data and DCD sections (which start at 0x60001000) are also very different.

It seems that these differences cause the application to fail to run.  I manually removed the boot header from an MCUExpresso based binary image and loaded it using Secure Provisioning Tool directly, and it did successfully execute from Flash (although very slowly).  But this doesn't fix the FDCB section, which seems cause the poor execution performance.

It looks like the flashloader function "flexspi_nor_generate_config_block_adesto_octalflash" is responsible for setting up the FDCB section, these settings are different than the MCUXpresso settings which seem to be set by "evkmimxrt1060_flexspi_nor_config.c"

Is it possible that the FDCB configuration for the Adesto Octal flash is incorrect or hasn't been updated in the SDK example for the flashloader and the flashloader included with Secure Provisioning Tool / MCUBootUtility?

Here are some screenshots highlighting my findings:

This is the flash config for xip in an MCUXpresso application project:

This looks to be the corresponding flash configuration in the flashloader code:

thanks

[jackking]

Hello,

I am trying to use the NXP Secure Provisioning Tool v2.1 to upload an XIP application to an Embedded Artists i.MX RT1062 board which uses the Adesto EcoXIP (ATXP032) for Flash.

Using MCUXpresso (and J-Link debugger) the application uploads and runs fine.
Switching to Secure Provisioning Tool (or NXP MCUBootUtility) the application uploads, but cannot execute.

I am using the flashloader that comes with Secure Provisioning Tool and I have also tried using a custom flashloader.bin based on the MCUboot SDK example in MCUXpresso SDK 2.8.6

I used MCUBootUtility to read out the flash memory (from location 0x60000000) to compare the two binary images.

There are some substantial differences between the two methods.
Specifically, the Flash Device Config Block (which starts at 0x60000000) is different.  Then the IVT, Boot Data and DCD sections (which start at 0x60001000) are also very different.

It seems that these differences cause the application to fail to run.  I manually removed the boot header from an MCUExpresso based binary image and loaded it using Secure Provisioning Tool directly, and it did successfully execute from Flash (although very slowly).  But this doesn't fix the FDCB section, which seems cause the poor execution performance.

It looks like the flashloader function "flexspi_nor_generate_config_block_adesto_octalflash" is responsible for setting up the FDCB section, these settings are different than the MCUXpresso settings which seem to be set by "evkmimxrt1060_flexspi_nor_config.c"

Is it possible that the FDCB configuration for the Adesto Octal flash is incorrect or hasn't been updated in the SDK example for the flashloader and the flashloader included with Secure Provisioning Tool / MCUBootUtility?

Here are some screenshots highlighting my findings:

This is the flash config for xip in an MCUXpresso application project:

This looks to be the corresponding flash configuration in the flashloader code:

thanks

[jackking]

Hello,

I am trying to use the NXP Secure Provisioning Tool v2.1 to upload an XIP application to an Embedded Artists i.MX RT1062 board which uses the Adesto EcoXIP (ATXP032) for Flash.

Using MCUXpresso (and J-Link debugger) the application uploads and runs fine.
Switching to Secure Provisioning Tool (or NXP MCUBootUtility) the application uploads, but cannot execute.

I am using the flashloader that comes with Secure Provisioning Tool and I have also tried using a custom flashloader.bin based on the MCUboot SDK example in MCUXpresso SDK 2.8.6

I used MCUBootUtility to read out the flash memory (from location 0x60000000) to compare the two binary images.

There are some substantial differences between the two methods.
Specifically, the Flash Device Config Block (which starts at 0x60000000) is different.  Then the IVT, Boot Data and DCD sections (which start at 0x60001000) are also very different.

It seems that these differences cause the application to fail to run.  I manually removed the boot header from an MCUExpresso based binary image and loaded it using Secure Provisioning Tool directly, and it did successfully execute from Flash (although very slowly).  But this doesn't fix the FDCB section, which seems cause the poor execution performance.

It looks like the flashloader function "flexspi_nor_generate_config_block_adesto_octalflash" is responsible for setting up the FDCB section, these settings are different than the MCUXpresso settings which seem to be set by "evkmimxrt1060_flexspi_nor_config.c"

Is it possible that the FDCB configuration for the Adesto Octal flash is incorrect or hasn't been updated in the SDK example for the flashloader and the flashloader included with Secure Provisioning Tool / MCUBootUtility?

Here are some screenshots highlighting my findings:

This is the flash config for xip in an MCUXpresso application project:

This looks to be the corresponding flash configuration in the flashloader code:

thanks

[gusarambula]

Hello Jackking,

This is an interesting analysis, although I cannot confirm if that would be the case as I’m not familiar with this board. The Embedded Artists i.MX RT1062 OEM board is manufactured and supported by Embedded Artists. They do provide a customized SDK

https://www.embeddedartists.com/products/imx-rt1062-oem/

Was the FDCB comparison from this SDK? If that’s the case I would suggest contacting Embedded Artists for support on their SDK customizations.

My apologies for the inconvenience.

Regards,
Gustavo

[jackking]

I will ask EA, but the SDK is the standard NXP SDK, Embedded Artists just provides a few patch files for the standard NXP SDK (on Mac). 

The flashloader example includes Adesto EcoXIP code directly from NXP (not provided by Embedded Artists).

I did a diff on the Windows version of the EA SDK and there aren't any core differences in the mcu-boot project

[Robert123]

Hi @jackking . Did you get any answers from Embedded Artists? I think I have the same issue here: https://community.nxp.com/t5/i-MX-RT/Run-bootloader-from-application-rt1062/m-p/1282335#M14372

[jackking]

No, I did not.  I just switched to using the binary image directly from MCUXpresso IDE, instead of creating it in Secure Provisioning. 

You can load a raw binary in Secure Provisioning so I just avoid the issue altogether, although it would be great if this were fixed.

[marek-trmac]

Hi jackking,

we are planning to support bootable image produced by MCU IDE/Keil/IAR as input for Build in Secure Provisioning Tool. FCB specified in the image shall be reusable in Secure Provisioning Tool too.

Regards

Marek

[Robert123]

Thanks, but I am still having problems (error message kStatus_FlexSPINOR_SFDP_NotFound) when using the raw binary from the MCU IDE. Is there some other problem with the FCB for the Adesto Flash?

[gusarambula]

Hello Jackking,

My apologies, you are right. There was support for some of Adesto’s Serial Flash memories, but chances are these haven’t been updated on the SDK example or some of the latest releases of the tools.

https://www.nxp.com/docs/en/white-paper/NXPADESTOWP.pdf

Regards,
Gustavo