TM4C1294NCPDT: VDDA, reprogramming, low VDD

Alex Halfin said:

Do we have to power up VDDA before VDD? In the comment taken from the datasheet of this MCU (page 1820) it is not clear enough? Anyway in our board as in the schematics of TI's evaluation board (SPMU365C) VDDA and VDD are connected to the same source. 

It is acceptable to have them connected to the same supply.

Alex Halfin said:

We have discovered that by mistake supply voltage to this MCU was ~3.085V (instead of nominal 3.3V). In the datasheet minimum voltage is 2.97V (as described on Table 27-6). What do you think it can cause us a problems in some circumstances?

With that low nominal voltage it is more likely that voltage dips caused by increasing current demands or by supply fluctuations will cause a Power-On reset. If the voltage NEVER drops below 2.97V, then the device will operate properly.

Alex Halfin said:

In some cases in order to get the boards working we had to reprogram (???) the boards, as we think that the boards were initially programmed. Is it possible that somehow the flash memory inside the MCU was damaged or erased? Or maybe there was some kind of locking state of this MCU?

The TM4C1294 devices are shipped from the factory with the flash originally blank (erased). My expectation is that all devices would  require programming.

Bob 

Thank you for your answer.

I know that the flash shipped blank from the factory.

Let me sharpen my third question.

In our application we have an MCU connected to the RJ45 connector from one side and to DAC from another side.

We are sending DAC's voltage levels setup through the ethernet.

We encountered a problem when in the field suddenly we are losing ethernet communication to the MCU.

Because of the COVID-19 we have difficulties to diagnose this problem properly when the board installed in our customer site.

But we suspect that the problem is in the MCU that getting dead from some reason. One of the reasons could be that MCU can't load a firmware image from the internal flash memory.

Personally I have encountered a problem when several boards that supposed to be programmed by our assembly subcontractors had to be reprogrammed by me in order to get them working.

I suspect that maybe something caused to already programmed firmware inside this MCU to be erased or damaged.

And this also happened to the boards failure in the field (when this board that was tested and verified before shipment is suddenly dead in the field).

The boards are not burned but just stop working.

According our embedded software engineer there is no chance that firmware intentionally access the flash inside the MCU and erase it or damage it.

My question do you have any ideas what is going on with this MCU in our case?

Alex

I do not have any idea what is happening to your units in the field. I am not aware of any reports of other customers having a similar problem. There is a mechanism to erase the internal flash, but it is quite a complex sequence and I have never heard of it being invoked accidentally. That sequence is described starting on page 213 of the datasheet. https://www.ti.com/lit/ds/symlink/tm4c1294ncpdt.pdf

There is also a function in the ROM for erasing a 16KB block of flash. If that function were accidentally executed by runaway code, it could erase one block of flash. I suspect your two issues are different. The unprogrammed units from the assembly site are likely just that, units that for some reason did not get programmed. Is there an outgoing test at the assembly site? 

To understand the field failures you will need to get a failed unit returned. Then you can verify the flash contents against the intended image.