S32K148: Mass Erase and Application upgrade

[hemadri_payam]

Hi,

I have an application running in RAM.

It mass erases the flash from 0x0000_0000 through 0x13FFFF_FFFF.

And upgrade the flash with the latest application.

No problem is observed if the process is not interrupted after mass erase and upgrade.

If the process is interrupted after mass erase, the bytes at the location 0x40C and 0x40D ends up with 0xFF and the board needs to be bricked.

I have referred to the mass erase issue in all other threads.

https://community.nxp.com/t5/S32K/Erase-all-blocks/td-p/1066429

https://community.nxp.com/t5/S32-Design-Studio/S32-Design-Studio-Flash-Mass-erase/m-p/826467

https://community.nxp.com/t5/S32K/S32K144EVB-Board-stuck-after-mass-erase/m-p/698482

But couldn't get any solution for my problem.

Can you suggest any better way to solve the issue.

Hemadri

[danielmartynek]

Hi Hemadri,

I don't know the exact use case but I would recommend keeping the first sector (with the vector table and the configuration field) always there and erase the rest of the block by sectors. It could jump from the first sector to the new application.

Once the MCU is secure the debugger can read the MDM_AP registers to determine the state of the MCU.

What debugger/programmer do you use?

Thank you,

BR, Daniel

[hemadri_payam]

Hi Daniel,

Thanks for your response.

Use case: To upgrade the application in the flash.

The code which upgrades the application is launched onto RAM and is running in RAM. It erases the flash and updates with the next version of the application.

Debugger/Programmer: Lauterbach, Trace32

As you suggested, we could keep the first sector unerased and update only the text section from the second sector.

The first sector contains ISR_VECTOR and FLASH_CONFIG. In the future, if the ISR_VECTOR changes for any reason, then we will not be able to update the first sector when the product is in the field. 

This is the concern we have.

Hemadri

[danielmartynek · Accepted solution]

Hi Hemadri,

You can have a bootloader and its vector table in the first sector, and this vector table does not change unless the bootloader is updated.

And the application has its own vector table.

I still don't see any reason why you need to erase the first sector.

With Lauterbach/Trace32, you can read the MDM-AP registers.

Please keep the MCU in reset after POR - connect PTA5 to GND and power-cycle the MCU.

And step through this script:

system.CPU S32K148
wait state.power()
system.attach

JTAG.PIN Enable
JTAG.PIN NRESET LOW

;read MDM-AP Status Register
PRINT "MDM-AP Status Register is 0x" Data.Long(EDBG:0x40000100)
;read MDM-AP Control Register
PRINT "MDM-AP Control Register is 0x" Data.Long(EDBG:0x40000104)

IF (Data.Long(EDBG:0x40000100)&0x04)==0x04
PRINT " Device secured"
ELSE
PRINT " Device is not secured"

IF (Data.Long(EDBG:0x40000100)&0x20)==0x20
PRINT " Mass erase enabled"
ELSE
PRINT " Mass erase disabled"

IF (Data.Long(EDBG:0x40000100)&0x02)==0x02
PRINT " Flash ready"
ELSE
PRINT " Flash is not ready"

WHILE((Data.Long(EDBG:0x40000100)&0x00000002)==0x0)
(
)

IF (Data.Long(EDBG:0x40000100)&0x02)==0x02
PRINT " Flash ready"
ELSE
PRINT " Flash is not ready"

Regards,

Daniel

[hemadri_payam]

Hi Daniel,

Thank you so much for the solution.

Hemadri