XIP_BOOT_HEADER_ENABLE Symbol Effect

[D_TTSA]

Good day

What effect does the value of the XIP_BOOT_HEADER_ENABLE pre-processor directive have?

This symbol must be 0 in both my projects (I have a multi-core MCUXpresso project) for me to flash my processor with the MCUXpresso Secure Provisioning Tool. For more on this, see my other post.

Changing the value between 0 and 1 doesn't have an obvious effect on the operation of my projects. 

Clearly something is happening in the background though. Can someone explain this to me please?

[kerryzhou]

Hi @D_TTSA 

  Please check this application note, you will be clear:

https://www.nxp.com/docs/en/application-note/AN12107.pdf

XIP_EXTERNAL_FLASH

1: Exclude the code which will change the clock of flexspi.
0: make no changes.

It will determine whether your generated app.srec/bin/hex etc file contains the FCB area or not.

 In fact, the SPT tool can support both the app contains the FCB or not, but I suggest you set it as 0, then the SPT tool will help you add the FCB when you download the code.

  If you still not clear, a simple way for you to learn it, you can set XIP_EXTERNAL_FLASH=0, generate the .srec file, then set XIP_EXTERNAL_FLASH=1, generate the .srec file. Then compare the two file, you will find the detail.

From code viewpiont, it is this code add or not:

const flexspi_nor_config_t qspiflash_config = {
.memConfig =
{
.tag = FLEXSPI_CFG_BLK_TAG,
.version = FLEXSPI_CFG_BLK_VERSION,
.readSampleClksrc=kFlexSPIReadSampleClk_LoopbackFromDqsPad,
.csHoldTime = 3u,
.csSetupTime = 3u,
// Enable DDR mode, Wordaddassable, Safe configuration, Differential clock
.controllerMiscOption = 0x10,
.deviceType = kFlexSpiDeviceType_SerialNOR,
.sflashPadType = kSerialFlash_4Pads,
.serialClkFreq = kFlexSpiSerialClk_133MHz,
.sflashA1Size = 16u * 1024u * 1024u,
.lookupTable =
{
// Read LUTs
FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0xEB, RADDR_SDR, FLEXSPI_4PAD, 0x18),
FLEXSPI_LUT_SEQ(MODE8_SDR, FLEXSPI_4PAD, 0x00, DUMMY_SDR, FLEXSPI_4PAD, 0x04),
FLEXSPI_LUT_SEQ(READ_SDR, FLEXSPI_4PAD, 0x04, 0, 0, 0),
},
},
.pageSize = 256u,
.sectorSize = 4u * 1024u,
.ipcmdSerialClkFreq = 0x1,
.blockSize = 256u * 1024u,
.isUniformBlockSize = false,
};

  Wish it helps you!

  If you still have questions about 

BR,

Kerry

[D_TTSA · Accepted solution]

@kerryzhou I don't understand what you said.

For someone who is looking for a detailed explanation, this is what my team found out from our own research:

The XIP_BOOT_HEADER_ENABLE pre-processor symbol controls whether the flexspi config block, IVT, boot data and DCD (optional) is added to the build's image or not. If it is 1, this information is added, if it is 0, the information is omitted. It must be 0 to load the project to the processor via ISP (with MCUXpresso Secure Provisioning Tool), because this information is added to the image during this process. This symbol must be 1 to load the project to the processor via debugging probe, otherwise this information is not written to the internal flash.
According to the RT1170RM (see below), the target will be reset if the IVT validity check fails. The trap is that the IVT validity check will pass if you at first load your project with this symbol = 1, and then later change it to 0 in the project settings. The IVT will be correctly saved in flash, and it will not be overwritten until you debug a project with this symbol equal to 1. Because the initial testing worked with this symbol equal to zero, we assumed that everything was fine. Later on, we debugged another project. Then when we debugged our project again, it only worked during the same power-cycle session as a debug. After a power-cycle, the board would stay in reset. This was because the IVT information persisted from the ‘other’ project we debugged. This caused the IVT validity check to fail, resulting in a reset.