TM4C1294NCPDT: Program chip, verify failed.

Hi IgDor,

  I have a few questions.

Is this your custom chip or the LaunchPad? Seems like it is the LaunchPad.

Which bootloader did you load into the chip? Is it one of the TivaWare bootloader examples?

Can you try to erase the flash instead of reloading another program image?

Can you also try Uniflash to either program or erase the chip?

Lastly, if above does not solve the problem can you try to unlock the chip using LM Flash Programmer? You can unlock the chip under the Other Utilities tab of LM flash programmer.

Hi IgDor,
What debug probe do you have for your custom board? The ICDI is on LaunchPad only. Are you using the LaunchPad as a debug probe to program/debug your customer board?

Hi Charles.

One more thing to try is to first erase the entire flash and follow with a blank check. Does it pass or fail?

Yes, it passed O.K.

I tried programmed this board with two different ICDI boards, and with UniFlash tool as well.

The result the same, "The verify failed".

This error occurs only with the one board. All others boards are programed O.K.

One more thing, when I upload flash several times, after one programming, the result is different. The errors are on different bits and  different addresses.

I'm very worried that this happened when I was updating FW over bootloader.

Is there the process that returns the chip to totally default state?

Best Regards.

Hi IgDor,

IgDor said:

I'm very worried that this happened when I was updating FW over bootloader.

 Sorry, let me try to understand you better. I assume it is the bootloader that you try to program into the flash via the JTAG interface having the program verify issue, correct? I'm a bit confused when you said updating the FW over bootloader. The FW is your application that is loaded/updated via some communication interface such as UART when the bootloader is run. I want to make sure which part is having the program verify issue. Is it the bootloader itself via the JTAG or the FW (application) via your specified communication port that you try to update to the flash?

  Can you try to load any program besides the bootloader? Is it just the bootloader program having the program verify issue? Try to load any TivaWare examples and see if you still get program verify fail. I will assume you will fail. If you continue to see program verify failure when loading any programs then I think the chip is bad. 

Hi Charles.

Sorry, I not clearly explained. 

 This board was programmed via JTAG(ICDI interface) and worked properly.

For FW update we use an Ethernet based bootloader. As I wrote in first post:

 "After updating the TM4C1294NCPDT chip with bootloader, it stopped working.

I tried reprogram the chip via JTAG(ICDI interface) with LM Flash Programmer, but after programming the verify failed."

Thus, the problems began after the FW update with the bootloader.

The problem is only on one board. All others boards (about 100) don’t have such problem.

Regards.

Hi IgDor,

 Thanks for the clarification.  

IgDor said:

"After updating the TM4C1294NCPDT chip with bootloader, it stopped working.

Can you please tell me is it the bootloader stopped working or the FW (application) stopped working?

IgDor said:

I tried reprogram the chip via JTAG(ICDI interface) with LM Flash Programmer, but after programming the verify failed."

 What did you try to reprogram via the JTAG ICDI? Is it the bootloader itself or the FW? 

Can you use your bootloader to download other FW such as TivaWare example boot_demo_emac_flash? Will you see any differences compared to your own FW?

Anyway, if you have other 100 boards that are working except this one board with the same setup then it leads me to think the chip is somehow not performing as expected.  

Hi Charles.

 Can you please tell me is it the bootloader stopped working or the FW (application) stopped working?

The board stopped working after the bootloader completed work and board make reset(FW should start to work)

What did you try to reprogram via the JTAG ICDI? Is it the bootloader itself or the FW?

Any FW. I tried to program the bootloader, FW, others .bin files, tried with different "Program Address Offset", the result is the same "Verify failed".

I uploaded flash with "LM Flash Programmer" and compare it with source file, data on several addresses, always one bit of a byte, does not match to source file. 

As I wrote in previous post if I upload flash several times, after one programming, and compare it with source file the result is different. The errors are on different bits and different addresses. Thus every uploads(the same flash content) I receive different errors.

This is a very strange malfunction, I can erase flash, program flash, set MAC address, unlock device, only flash is programmed/read with errors.

Can programming flash lead to defect the chip?

If I will use another debugger (XDS100, XDS200, JLink, etc), can I more manage the chip?

Which of these debuggers is better?

One chip does not really matter, but we have customers around the world, and sometimes they have to do an FW update, and if this happens often it will be a big problem for us.

Regards

Hi IgDor,

 I understand your frustration.  Can you do one more experiment and answer me some questions?

 Can you use the TivaWare boot_emac_flash as the bootloader and first load it into the flash using JTAG ICDI. You will then use the bootloader to download the boot_demo_emac_flash example via the ethernet interface. After the boot_demo_emac_flash is loaded you will reload the same boot_demo_emac_flash but this time you will load the FW (boot_demo_emac_flash) using the JTAG ICDI interface. If you use the TivaWare examples will you still get program verify failure?

 Below is what I did.

 1. First load the boot_emac_flash  using JTAG inteface. I load the program in CCS.

 2. Run the boot_emac_flash  

 3. In LM flash programmer I change to the ethernet interface as shown below. Your IP address and MAC address will be different from mine.

4. Specify the boot_demo_emac_flash.bin file. and click the Program.

5. Once the boot_demo_emac_flash.bin is loaded you will change back to JTAG ICDI interface like below. Note I'm using a LaunchPad and hence select the TM4C1294XL LaunchPad.

6. This time, reprogram the same boot_demo_emac_flash.bin again via ICDI. Note I selected Erase Necessary Pages radio button so it will not erase the bootloader. Also I selected the Verify After program radio button. For the offset, I use 4000 since this is the offset address when the boot_demo_emac_flash was built. You can see that after the program the CRC will check and pass in my case. Let's see what your result is. 

Now comes some question. You said that all the other 99 boards are working. I want to make sure when you said the other 99 boards are working, they are subject to the identical FW update procedure compared to the problem board. Meaning that with the good boards, after the FW is updated and if you attempt to reprogram the same FW image via ICDI it will pass.

IgDor said:

Can programming flash lead to defect the chip?

If I will use another debugger (XDS100, XDS200, JLink, etc), can I more manage the chip?

Which of these debuggers is better?

 

One chip does not really matter, but we have customers around the world, and sometimes they have to do an FW update, and if this happens often it will be a big problem for us.

I cannot rule out if there is a defect with the chip. But normally, programming flash should not defect the chip unless you have exceeded the maximum program/erase cycles specified in the datasheet which I doubt.

 You can try with any of the debug probes of your choice. XDS may be cheaper. Some forum members have excellent review for JLink but may be of higher cost. You will need to make your own decision based on different pros and cons. 

I hope this is an isolated incident and this is why I want to make sure you have at least try with other good boards with the identical FW update procedure. Whatever procedure you use on the bad board to replicate the problem you can execute the same on the good boards and they will pass. 

Hi Charles.

I tried to program the "boot_emac_flash" project, but in CCS the same problem –"Verification failed".

Now comes some question. You said that all the other 99 boards are working. I want to make sure when you said the other 99 boards are working, they are subject to the identical FW update procedure compared to the problem board. Meaning that with the good boards, after the FW is updated and if you attempt to reprogram the same FW image via ICDI it will pass.

 Most of these boards are at customers, and so far we didn't make overall FW update(were updated only few of them). But the boards that we have at the office(for debug, QA etc.) we  updated/reprogram dozens times without problem.

The problem board was programmed only two times. The bootloader was programmed via ICDI, then FW was loaded via bootloader, the board worked correctly, and after some time we updated the FW to a new version(via bootloader), it stopped working.

 I also hope that it is an isolated incident, but, in my experience, if something strange and unexplained happens, it will happen again.

Thanks for your help.

Regards.

Hi IgDor,

 If you have a chance, one more thing I can think of for you to check is the power supply to the MCU. Please make sure if you have proper and stable power supply to the device. If not too much work for you, see if you can swap in a new MCU in the bad board. This way we can fully rule out if the problem is chip level or board level.

In the screenshot you have it says Writing Flash @ Address 0x00004000..... This is a bit weird. The boot_emac_flash should start at 0x0, not 0x00004000. Had you rebuilt the project in the past with different address offset? Can you please check the bl_link_ccs.cmd that comes with the boot_emac_flash example?

Lastly, can you check the flash configuration as shown below. Do you have the Entire Flash option radio button checked for erase? The reason I'm asking is because earlier you said you tried to run the blank check in LM flash programmer and it was passing?  If you just click the Erase Flash button, will it pass?

Hi Charles.

Please make sure if you have proper and stable power supply to the device.

I checked with oscilloscope all voltage, VDD 3.3V and VDDC 1.2V. All voltages are clears, without dropping. Also I checked the board with several different PSU.

 Also I checked, with oscilloscope, all JTAG signals. It seems O.K.

In the screenshot you have it says Writing Flash @ Address 0x00004000..... This is a bit weird. The boot_emac_flash should start at 0x0, not 0x00004000. Had you rebuilt the project in the past with different address offset? Can you please check the bl_link_ccs.cmd that comes with the boot_emac_flash example?

Here is screenshot from original boot_demo_emac_flash_ccs.cmd file.

I changed the APP_BASE to 0x0 and tried to debug again, the result is the same "Verification Failed"

Lastly, can you check the flash configuration as shown below. Do you have the Entire Flash option radio button checked for erase?

Yes it set to Entire Flash erase.

The reason I'm asking is because earlier you said you tried to run the blank check in LM flash programmer and it was passing?  If you just click the Erase Flash button, will it pass?

Yes, I did "Erase Flash" many times, it always pass.

 If not too much work for you, see if you can swap in a new MCU in the bad board. This way we can fully rule out if the problem is chip level or board level.

While I will not do it.  May be I will check something yet.

Regards.

Igor.