TM4C123GH6PM: Program flash erasing

Hello Luigi,

I've been scouring through possible erratum and looking for any similar reports, and I haven't found anything that would explain the behavior you've outlined here.

I can't barely even think of a situation where the board flash would be completely erased like this due to a programming issue. Maybe a boot loader that is loaded into SRAM and then clears all Flash somehow but even that is farfetched because you would not overwrite the boot loader portions.

When you re-flash the board, have you ever been able to re-observe the situation occurring once again?

Have you tried placing these 'failed' boards back into your automatic testing procedure? What is the result?

Perhaps something that could help is to adjust your programming procedure to do a blank check after programming. It should fail immediately, but in the cases where a program isn't loaded right, then you could catch it in that manner.

thank you for your message.

We will introduce a Flash check at the end of the testing procedure.

We are now reloading program into faulty units and testing again.

On the banch the Flash have not erased any more after reloading it.

We need to check it in the working environment. Working environment is inside power converter with high current commutating behind.

There are any hardware shortcuts or exceptions that can delate the Flash?

Do you know if the program is loaded into RAM or is executed fatching instructions from Flash?

Thanks and regards.  

Hello Luigi,

There is nothing that would cause the flash to be completely deleted like this in terms of hardware exceptions/faults/erratum etc.

Programs can execute from RAM when designed that way. The TivaWare and ROM bootloaders do this because of Erratum like MEM#14: www.ti.com/.../spmz849f.pdf However, outside of these specifically designed scenarios, programs will otherwise always execute in Flash.

But to erase all the flash like you described would mean a function executing from RAM that erases a flash block goes haywire and systemically erases every since block of Flash. As mentioned, I've just not run into any situation where the entire Flash programming of the device was accidentally erased after programming.

Everything about this indicates that either the program was not Flashed to begin with, so unless the issue manages to be re-produced now that the boards have been properly Flashed again, I think that needs to be the approach taken here. That is why some of my questions were to evaluate if there was some manner that it could have incorrectly passed your test program somehow.

Ralph Jacobi said:

As mentioned, I've just not run into any situation where the entire Flash programming of the device was accidentally erased after programming.

The debug unlock sequence can perform a mass erase of the flash. How likely is it that "noise" on the JTAG pins while the device is held in reset could trigger a mass erase?

Hello Chester,

An interesting theory, but statistically impossible for noise to cause it given the sheer number of steps required:

1. Assert and hold the RST signal.
2. Apply power to the device.
3. Perform steps 1 and 2 of the JTAG-to-SWD switch sequence on the section called “JTAG-to-SWD
Switching” on page 207.
4. Perform steps 1 and 2 of the SWD-to-JTAG switch sequence on the section called “SWD-to-JTAG
Switching” on page 207.
5. Perform steps 1 and 2 of the JTAG-to-SWD switch sequence.
6. Perform steps 1 and 2 of the SWD-to-JTAG switch sequence.
7. Perform steps 1 and 2 of the JTAG-to-SWD switch sequence.
8. Perform steps 1 and 2 of the SWD-to-JTAG switch sequence.
9. Perform steps 1 and 2 of the JTAG-to-SWD switch sequence.
10. Perform steps 1 and 2 of the SWD-to-JTAG switch sequence.
11. Perform steps 1 and 2 of the JTAG-to-SWD switch sequence.
12. Perform steps 1 and 2 of the SWD-to-JTAG switch sequence.
13. Release the RST signal.
14. Wait 400 ms.
15. Power-cycle the microcontroller.

And the switch sequences Steps 1 and 2 are:

JTAG-to-SWD:

1. Send at least 50 TCK/SWCLK cycles with TMS/SWDIO High to ensure that both JTAG and SWD
are in their reset states.
2. Send the 16-bit JTAG-to-SWD switch command, 0xE79E, on TMS/SWDIO

SWD-to-JTAG:

1. Send at least 50 TCK/SWCLK cycles with TMS/SWDIO High to ensure that both JTAG and SWD
are in their reset states.
2. Send the 16-bit SWD-to-JTAG switch command, 0xE73C, on TMS/SWDIO.

So that would imply noise not only sends 50 cycles 10 times, but also sends the commands 0xE79E and 0xE73C 5 times successively in alternating patterns. I would say that is safe from an noise induced mass erases.

Not yet Ralph. We sent two failed samples to TI for further analysis. The faulty microcontrollers , when reprogrammed, seems not to loose data again. We faced about 10 cases, some of these at first power on, some at successive power on, some during the operation of the system. We are not power cycling 10 times all products during final testing. We are waiting from TI analysis of the content of Flash in 2 failed devices. Regards.

Hello Luigi,

Okay, thank you for the update. Let me know when you get back information from the FA team (I don't have direct visibility into that usually).