Dear NXP, hello:
Our company's K148 has two partitions: a bootloader and an application partition. The application partition has a function to disable JTAG. When JTAG is disabled in the application, the bootloader fails to start after a reset, causing the chip to become bricked. Investigation revealed that the bootloader is 32KB, ranging from 0x00 to 0x8000. Disabling JTAG involved writing 0xFFu , 0xFFu , 0xFFu , 0xFFu , 0xFCu, 0x7Fu , 0xFFu , 0xFFu at address 0x408 , causing a change in the flash content. After a reset, the CSEc calculates a different boot_mac value for the bootloader, resulting in the bricking. Does NXP have any mature solutions to resolve this issue? Thank you.
Hi, @lukaszadrapa
According to the manual above, BOOT_MAC is a one-time, irreversible write. Is there an official API that allows changing its value? If so, could you provide this API?
Using your company's FS32K144HFT0MLHT MC 
Hi @vurtual
The common approach is to disable the debug interface during manufacturing, rather than later from the application. In that case, the process can be done in a single production step: reprogram the Flash Configuration Field (FCF) to disable the debug port and then provision the correct BOOT_MAC value (or allow the CSEc to calculate it automatically after the next reset).
If you need to disable the debug interface later in the product lifecycle, that is also possible. However, once the FCF is reprogrammed, the BOOT_MAC must be updated as well, since the secure boot calculation includes the modified FCF contents. Otherwise, the secure boot verification will fail.
The BOOT_MAC can be updated using the standard SHE memory update protocol, in the same way that CSEc keys are updated. After updating the BOOT_MAC to match the new FCF contents, secure boot should operate correctly with the debug port disabled.
Regards,
Lukas
Hi @vurtual
Where do you see that this is an irreversible operation? That is not correct. BOOT_MAC can be updated.
As I mentioned previously:
"The BOOT_MAC can be updated using the standard SHE memory update protocol, in the same way that CSEc keys are updated."
This means you can use the CMD_LOAD_KEY command, which is the same command used to import and update regular SHE/CSEc keys.
To update BOOT_MAC, you need to generate the M1–M5 values according to the standard SHE key update procedure. The key counter must be incremented, and the update can be authorized using either the MASTER_ECU_KEY or the BOOT_MAC_KEY.
Therefore, updating BOOT_MAC is a supported operation and is not irreversible.
Regards,
Lukas
Hello,@ lukaszadrapa
Our company uses your FS32K144HFT0MLHT MCU with an 8MHz passive crystal oscillator (AV08000009), and the waveform is abnormal. Is this crystal oscillator waveform acceptable for your MCU? Will it affect the normal operation of the MCU? Thank you.
Please create new thread for this. Thank you.