MCXA156 FLASH remapping through ROM Bootloader

[AlexRu]

Hello NXP-Community,

I am currently experimenting with the REMAP functionality of the MCXA Family (MCXA156) as it is seems to be an ideal method swapping 2 flash spaces when doing FW updating in field.

I am facing a problem now that I am not able to REMAP half of the available 1MB Flash of MCXA156 chip.  

According to the CMPA description in the reference manual attachments the tooltip hints that FLASH_REMAP_SZ represents 32KB increments for remapping range (see attached Screenshot:

In contrast the REMAP registers of FMC0 state an increment of 8KB (Chapter 7 Flash Memory Controller (FMC)):

When LIM = LIMDP = 0, FMC disables the remap function. When LIM = LIMDP = a nonzero value, the remapping address range is (LIM + 1) × 8 KB. For example:
•
When LIM = LIMDP = 1, the range is ≤ 16 KB.
•
When LIM = LIMDP = 2, the range is ≤ 32 KB.

The value of FLASH_REMAP_SZ is copied into LIM and LIMDP field of the REMAP register. (by ROM Bootloader?) Unfortunatelly the maximum value that can be set according to CMPA description is 0x1E. With this value I confirmed that 30 * 8KB range is mapped from lower half to upper half flash.

For further context: I am able to map the desired 512KB by directly writing 0x3F into LIM and LIMDP fields within my experimental SW. I am unsure whether this is a clean way of doing flash remapping or is there a better way executing it?

Question:

Is it correct that the value of FLASH_REMAP_SZ from CMPA is "copied" by the ROM Bootloader?

Is it possible to trick or workaround the limitiation of FLASH_REMAP_SZ size and be able to increase the range for remapping? (> 0x1E)

Best regards

Alex

[Harry_Zhang · Accepted solution]

Hi @AlexRu 

Based on the information from sections 20.5.4, 7.3.6, and 7.6.1.2 of the user manual, the following conclusions can be made:

 

1. The actual flash remapping range is determined by the FMC.REMAP register (LIM/LIMDP) with an 8 KB granularity.
The REMAP register defines remap_address[19:13], meaning the remap size is (LIM + 1) × 8 KB.
For a 1 MB flash device, the lower half is 512 KB, so the maximum valid LIM value is 0x3F, allowing a full 512 KB swap.

2. The CMPA field FLASH_REMAP_SZ is only a boot-time default value loaded by the ROM Bootloader.
Its maximum allowable value is a limitation of the CMPA structure/ROM—not a hardware limitation.

3. Configuring FMC.REMAP at runtime is an officially supported mechanism.
The REMAP register uses a key-write scheme (A5A5/5A5A), and writes are allowed unless REMAPLK is set.
This clearly indicates that user software is allowed to update LIM/LIMDP to any value permitted by hardware.

BR

Harry

[AlexRu]

Hello Harry, thank you for the quick response and confirmation.
Do you have any further documents or details on the functionallity of the ROM Bootloader (+ Extended Bootloader)?
To my understanding it is intended by NXP to use the ROM API for a defined write procedure into the FLASH.
Does NXP recommend to use special "margin read" commands after programming to verify the quality of FLASH programming gate charge?
Or is it enough to readback over the FLASH_VerifyProgram() command?
We are planing field updates for our application and want to maximize the durability of our System.
Appreciating your support!
Best regards
Alex

[Harry_Zhang]

Hi @AlexRu 

About the  ROM Bootloader document, i think you can refer to the MCXA156 reference manual MCXAP100M96FS6RM Chapter 20 and AN14525 

AN14525: MCXA14x/15x Secure Boot Based on MCUBoot | NXP Semiconductors.

MCXA's ROM Flash API does not include Margin Read.

The following are the supported functions.

typedef struct _flash_driver_interface
{
    /* Flash driver */
    status_t (*flash_init)(flash_config_t *config);
    status_t (*flash_erase_sector)(flash_config_t *config, uint32_t start, uint32_t lengthInBytes, uint32_t key);
    status_t (*flash_program_phrase)(flash_config_t *config, uint32_t start, uint8_t *src, uint32_t lengthInBytes);
    status_t (*flash_program_page)(flash_config_t *config, uint32_t start, uint8_t *src, uint32_t lengthInBytes);
    status_t (*flash_verify_program)(flash_config_t *config,
                                     uint32_t start,
                                     uint32_t lengthInBytes,
                                     const uint8_t *expectedData,
                                     uint32_t *failedAddress,
                                     uint32_t *failedData);
    status_t (*flash_verify_erase_phrase)(flash_config_t *config, uint32_t start, uint32_t lengthInBytes);
    status_t (*flash_verify_erase_page)(flash_config_t *config, uint32_t start, uint32_t lengthInBytes);
    status_t (*flash_verify_erase_sector)(flash_config_t *config, uint32_t start, uint32_t lengthInBytes);
    status_t (*flash_get_property)(flash_config_t *config, flash_property_tag_t whichProperty, uint32_t *value);
    /* IFR driver */
#if !(defined(FSL_FEATURE_ROMAPI_IFR) && (FSL_FEATURE_ROMAPI_IFR == 0U))
    status_t (*ifr_verify_erase_phrase)(flash_config_t *config, uint32_t start, uint32_t lengthInBytes);
    status_t (*ifr_verify_erase_page)(flash_config_t *config, uint32_t start, uint32_t lengthInBytes);
    status_t (*ifr_verify_erase_sector)(flash_config_t *config, uint32_t start, uint32_t lengthInBytes);
#endif
    status_t (*flash_read)(flash_config_t *config, uint32_t start, uint8_t *dest, uint32_t lengthInBytes);
    /* version */
    uint32_t version;
} flash_driver_interface_t;

BR

Harry