MPC5744P C55 Flash Driver, Erase Intermittent

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

MPC5744P C55 Flash Driver, Erase Intermittent

127 Views
andrew_smith
Contributor I

Dear all,

We're investigating two issues where specific sections of the flash are not erased as expected.

We are using the v.1.1.0 c-array software driver, and have not observed this problem until a new batch of hardware has been built. The MCUs have mask set 1N15P and date code CTBJ2308A.

There are no interrupts enabled, cache is disabled, code is running in RWW partition 1, and the flash being erased/programmed is in RWW partitions 4, 5 or 6. All blocks are unlocked.

Issue 1:

Software action during a full power down of the unit is to block copy contents of RAM into sections in flash (in partitions 4 or 5) and then to switch off the power.

What we see is that during the erase/program process, a machine check exception takes place - current thinking is this happens during the program-verify function when flash cells which were not successfully erased (and therefore, effectively have been double-programmed) are read.

The exception handler uses the MCAR register to identify which block contained the fault and attempts another erase of that block. The MCU is then rebooted. Software begins again, and copies a reserve set of flash data (i.e., is fully correct and not corrupted) into RAM. Application software will then immediately try to power down causing this same loop to repeat.

We see that after a certain number of cycles (normally between 3-8) through this process, the MCU is able to successfully erase the memory section, and the unit finally powers off. Using a debugger to look at the memory shows that erase was not completed successfully.

Issue 2:

Another unit shows the same issue (apparent failure to erase), but this time during application software download into RWW partition 6. This time a specific block 0x1080000 does not erase as expected. Memory at (for example) 0x1040000 is correctly programmed. All the other units in this batch program perfectly with the same software. 

Questions:

Other than supply voltage to the flash being unstable, are there any other hardware external factors which could influence flash programming capability?

Are there later flash drivers for this device available? We note that the mask is from 2018, but the driver is from 2015.

Has anyone else reported issues with MCUs having this date code? We haven't seen this problem with previous batches of units.

Thanks for any thoughts with this problem.

 

 

 

 

 

 

Tags (3)
0 Kudos
Reply
2 Replies

87 Views
davidtosenovjan
NXP TechSupport
NXP TechSupport

Flash driver is also present in the S32DS's SDK. In the version 3.0.3 it is stated date 2019. It should be newer and maintained.

I would point out following two errata

davidtosenovjan_0-1729597069377.png

davidtosenovjan_1-1729597112058.png

Check whether it may not be related to you configuration.

Specifically I am not aware of any known issues. There were some updates but these does not seem to cause mentioned behavior:
https://www.nxp.com/docs/en/engineering-bulletin/EB00921.pdf

Are you 'working' devices of the same mask?

 

0 Kudos
Reply

75 Views
andrew_smith
Contributor I

Thanks for your input David - yes all boards in the batch have the same mask set and date code.

We will look at using the SDK code instead of the former c-array driver software. ERR7989 does not apply, but there is potential for ERR8891.

Thanks again.

0 Kudos
Reply