topic Re: MC56F83XXX Programming fails if flash should be secured afterwards in Digital Signal Controllers

MC56F83XXX Programming fails if flash should be secured afterwards

258817 — Thu, 15 Jan 2026 09:25:00 GMT

Hi,

I have created my own programmer (HW/SW). With this device I'm already able to program MC56F84xxx (nevis) and MC56F82xxx (anguilla silver) with new software with or without secured flash and everything works fine.

Now I added the support for MC56F83xxx (nevis green). Everything works fine when flash remains unsecure. (I read the whole uC after programming and compare it to the SRecord which was flashed before -> equal)

But when I try to flash a SRecord with secured flash config inside I have problems. I read the ROM after programming inside the target APP but I receive 0x000.. for all config bytes (0x400-0x40f)

If I flash the same SRecord with a PEMicro Multilink Universal FX everything looks ok. Bytes in APP are correct and not 0x0000..

What special handling is needed for the config bytes when flash should be secured after flashing?
Special time when the config bytes have to be written? Special command??

Any documentation about that?

Re: MC56F83XXX Programming fails if flash should be secured afterwards

Celeste_Liu — Fri, 16 Jan 2026 11:11:31 GMT

Hello @258817 ,

Thanks for your sharing.

Have you tried using blhost?

https://www.nxp.com/webapp/Download?colCode=blhost_2.6.7&appType=license&location=null

After programming the secured firmware, you can run the flash-read-resource command in blhost to read the IFR and verify whether the configuration has been written correctly.

Please have a try. Have a nice day.

Celeste

Re: MC56F83XXX Programming fails if flash should be secured afterwards

258817 — Wed, 21 Jan 2026 14:59:26 GMT

Hi,
thanks for your reply.

At the moment I'm not able to use the bootloader (as this will require a hardware change of the target hardware)

But could you describe me the general process of flashing the uC(MC56F83663) over JTAG/EONCE

Is this approach correct:
-perform a mass erase and leave the uC in unsecure mode (FSEC=0xFE)
-FLash the uC programphrase by programphrase (each 8 byte) beginning at address 0x000000. No special handling for the connfiguration bytes (address 0x400-0x40F).

Is this in general correct?
Is any special handling required for configuration bytes from 0x400 to 0x40F

Best regards

Re: MC56F83XXX Programming fails if flash should be secured afterwards

Celeste_Liu — Fri, 23 Jan 2026 09:52:12 GMT

Hello @258817 ,

Hope you are doing great!

Is this in general correct?

->> Yes, it's basically correct. However, the memory range 0x400–0x40F must not be treated as a normal flash area without special handling.

Is any special handling required for configuration bytes from 0x400 to 0x40F

->> Yes. This 16‑byte region is the Flash Configuration Field, which directly controls system‑level behavior such as security, debug access, and erase permissions.

It is recommended to:

Program this region as a separate, explicit step with well‑defined values
Keep FCF_FLASH_SECURE_BYTE = 0x7E (unsecure and mass‑erase enabled) during the development phase
Carefully evaluate the unlock/recovery strategy before enabling security for mass production, to avoid permanently locking the device

Maybe you can refer to our SDK realization with Flash_config.c/Flash_config.h:

Hope it helps.

Celeste

Re: MC56F83XXX Programming fails if flash should be secured afterwards

258817 — Fri, 23 Jan 2026 13:35:18 GMT

@Celeste_Liu Thanks for your reply.

In the meantime I found a working solution for me:

After I did an erase all and leaving the MC56F83663 unsecured I need an additional erase sector command for 0x400

After that change in handling everything seems to work fin for the MC56F83XXX.

The other 2 supported families does not need this additional erase sector command (MC56F82XXX & MC56F84XXX)