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.
