S32k144 can not work

[fcb5511]

I got a problem recently, when I use cyclone to program S32K144, after that, the MCU can not work. then I download the elf file, try to debug,  I found the data in address range 0x400-0x40f are not correct, they are all become 0, after program again, the data in address range 0x400-0x40f recovery normal, ECU can work normally, is there any one meet this problem?

[Julián_AragónM]

Hi @fcb5511

Are you using S32DS, or an external program to flash with the Cyclone? Please check if this is the latest firmware recommended.

Does this always happen? Is this only with a specific project, or with any project (RTD example, empty project, etc...)?

[fcb5511]

I am using S32_SDK_S32K1xx_RTM_4.0.2 package, I have found some other information when follow the below steps:

1. erase all the chip.

2. flash S19 file with cyclone,(the data in range [0x400,0x40F] is   FF FF FF FF FF FF FF FF  FF FF FF FF FE 7F FF FF)

3. power off->power on, read the address range [0x400,0x40F], result is  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

4. modified the 0x40D(FTFC_FOPT) from 0x7F to 0xFF.

5. repeat step 1 to step 3, the MCU run normally.

the default FTFC_FOPT value  is defined as 0x7F in startup_S32K144.S, I checked the FOPT definition in S32K-RM, the bit4-bit7 are all reserved, I think the high four bits should not affect the programming, I don't know why 0x7F will cause the failure.

fcb5511_0-1745740629442.png

[Julián_AragónM]

Hi @fcb5511,

The FOPT[1] and FOPT[7] are meaningful only for initial version of S32K144 silicon (i.e. 0N77P) which has already been obsolete. For the newer S32K1X versions, they don't have a specific meaning. Reserved bits can be set to ‘1’.

Best regards,
Julián

[fcb5511]

Hi @Julián_AragónM 

The version of S32K1XX we are using is 0N57U,  why setting the The FOPT[1] and FOPT[7]  to 1 will cause the failure



Best Regards

[Julián_AragónM]

Hi @fcb5511,

I do not think the reserved bits are the issue. You mentioned you programmed the flash config as 0xFFFF7FFF, which means that the FSEC register is 0xFF = secured.

You are securing the MCU, and unsecuring by doing a mass erase when trying to connect again. 

The default value for the startup file is 0xFFFF7FFE; (0xFE = unsecured).

I've tested this configuration, and I can connect without issues, although I am debugging through the OpenSDA interface (functionality should be the same). I've tested both 0x7F & 0xFF and connection is the same. Try value 0xFFFF7FFE instead.

Julin_AragnM_0-1746036818858.pngJulin_AragnM_1-1746037087476.png

Best regards,
Julián

[fcb5511]

Hi @Julián_AragónM 

 I used 0xFFFF7FFE instead, not 0xFFFF7FFF, and my program tool is WinIDEA, I configured not to skip 400-40F address, and active mass erase before download.

fcb5511_0-1747119840034.png

the programming process will failed at 400-40F address, the 16 bytes all become 0x00, only the address before 0x400 were programmed successfully.

fcb5511_1-1747120046014.png

Best regards,

[Julián_AragónM]

Hi @fcb5511,

Are you able to connect with S32DS instead of WinIDEA? I have no personal experience with that specific SW, but according to their page, your step for securing the device is correct: JTAG Lock procedure on NXP S32K1xx.

Best regards,
Julián

[fcb5511]

update a detailed fault information

fcb5511_0-1747120718648.png