TM4C1290NCPDT: LM Flash Programmer Issue

Hi,

  With the flash erased, the ROM bootloader will boot up and enumerate the USB device port as a DFU device. I just try the DFU to download a simple blinky.bin using LM Flash programmer. I can repeatedly download a new firmware without a issue. I have only one PC to try though. 

I also use the command line dfuprog.exe to download the firmware. 

- I first erase the flash. 

- I will see two DFU capable devices on the LaunchPad. One is the ICDI on the USB debug port and the other is the Tiva DFU enumerated on the USB device port. 

- I'm not an expert on the Windows side but I see the driver version and date for the Stellaris Device Firmware Upgrade Properties. 

- I switch the Tiva DFU device to DFU mode. 

- I download the blinky.bin and I can see the LED blinking after download. 

Can you please provide the below information so we can narrow down the problem?

• It looks like the flash is erased and you are trying to use the ROM USB bootloader in DFU mode. Is this correct?
• Is this problem observed on a custom board or also on the LaunchPad?
• What is the driver data/version for your different computers? Are there any differences among them?
• Can you try on a LaunchPad. What is the result?
• Can you load a simple blinky.bin or hello.bin program? Will you see the same problem?
• Can you try dfuprog.exe. This is a command line tool to download firmware using USB in DFU mode. It is part of the TivaWare SDK. If not downloaded yet, please download from https://dr-download.ti.com/secure/software-development/software-development-kit-sdk/MD-oCcDwnGrsI/2.2.0.295/SW-USB-win-2.2.0.295.msi

Hello Charles,

Thanks for your answer.

I wrote Fabio for support and he created the thread here to inform you, so let me ask to your questions. Below my answers, plus some screenshots.

- It looks like the flash is erased and the customer is trying to use the ROM USB bootloader in DFU mode. Is this correct?

• Correct, but the flash is not always erased. We use BOOTCFG register method to invoke ROM USB bootloader, by connecting a certain GPIO (PG6) to ground at start-up. I believe the uC goes correctly into ROM USB bootloader since windows is able to detect the USB peripheral when I turn on the board in boot mode. In order to do that I follow this procedure: make the short to ground for PG6, connect our board via usb to the PC, start “LM Flash Programmer”, turn-on the board.

- Is this problem observed on a custom board or also on the LaunchPad?

• I would say only on the custom board, see next points for more details.

- What is the driver data/version for your different computers? Are there any differences among them?

• I tested the download procedure on two different PCs with the same driver version, The same board and the same USB cable was used for the test. On PC1 the procedure fails as described above by Fabio (next points refer to this PC), on PC2 the procedure works fine. For both PCs, the installed version of TivaWare is “TivaWare_C_Series-2.2.0.295”, nevertheless in “Device Manager” version 2.1.4 of driver is shown. Is this Ok? If I try to manually update the drivers and use the TivaWare directory “C:\ti\TivaWare_C_Series-2.2.0.295” to search for the drivers, Windows system tells me that the drivers are up to date. Some screnshots below.

          Same drivers on both PCs.

          PC1: download does not work.

          PC2: download works.

- With the flash erased, I just try the DFU to download a simple blinky.bin using LM Flash programmer. I have no issue.

- Can they try on LaunchPad if they have not yet tried. What is the result?

• I tried to load blinky.bin and hello.bin on the LauchPad via USB DFU, it worked fine also on my side. See the pictures below.

- Can they load a simple blinky.bin or hello.bin program? Will they see the same problem?

• Do you mean load blinky.bin or hello.bin on our custom board instead of our custom SW? In that case I tried on PC1 and the results are the same as showed in the pictures in the post above (ERROR -3, ERROR -4…), no flash is possible.

- Can they try dfuprog.exe. This is a command line tool to download firmware using USB in DFU mode. It is part of the TivaWare SDK. If not downloaded yet, please download from https://dr-download.ti.com/secure/software-development/software-development-kit-sdk/MD-oCcDwnGrsI/2.2.0.295/SW-USB-win-2.2.0.295.msi

I tried with the tool on PC1, see the results below.

LaunchPad:

• The board is listed in USB connected devices
• I can switch to DFU mode (it was already in that mode)
• I can upload blinky.bin

 Custom Board, I got 2 different scenarios:

• Scenario1:
  • The board is not listed in USB connected devices, the USB device is detected by Windows though. See picture below where “Gestione dispositivi” = “Device Manager”
  • I cannot proceed with further steps

• Scenario2:
  
  • The board is listed in USB connected devices
  • I can switch to DFU mode (it was already in that mode)
  • I cannot upload blinky.bin, ERROR -4 also here.

Angelo Traina said:

• I would say only on the custom board, see next points for more details.

Angelo Traina said:

• I tried to load blinky.bin and hello.bin on the LauchPad via USB DFU, it worked fine also on my side. See the pictures below.

Angelo Traina said:

LaunchPad:

• The board is listed in USB connected devices
• I can switch to DFU mode (it was already in that mode)
• I can upload blinky.bin

                

Based on the above information, the LaunchPad works on both PC1 and PC2. Is that a correct understanding?

I will suppose if you load your custom code to the LaunchPad, it will also work fine on both PC1 and PC2 using either LM flash programmer or dfuprog.exe. Is that also a correct understanding?

Angelo Traina said:

I tested the download procedure on two different PCs with the same driver version, The same board and the same USB cable was used for the test. On PC1 the procedure fails as described above by Fabio (next points refer to this PC), on PC2 the procedure works fine. For both PCs, the installed version of TivaWare is “TivaWare_C_Series-2.2.0.295”, nevertheless in “Device Manager” version 2.1.4 of driver is shown. Is this Ok? If I try to manually update the drivers and use the TivaWare directory “C:\ti\TivaWare_C_Series-2.2.0.295” to search for the drivers, Windows system tells me that the drivers are up to date. Some screnshots below.

Can you do an experiment? In Windows Device Manager, can you uninstall the Stellaris Device Firmware Upgrade device and then reinstall the driver. I wonder if that makes a difference on PC1. 

Angelo Traina said:

• Do you mean load blinky.bin or hello.bin on our custom board instead of our custom SW? In that case I tried on PC1 and the results are the same as showed in the pictures in the post above (ERROR -3, ERROR -4…), no flash is possible.

Do you have any custom board that will work on PC1 and PC2? Or you only have one board to test? The reason I ask is because if you have at least one board that works on PC1 and PC2 then you could do a ABA swap test - meaning to swap the MCU on the board that works for PC1 to the board that fails and vice versa. 

The A-B-A Swap Method is a simple cross check test, which can confirm the observed issue is not systemic.

• A-B-A Swap Method
  (1) Remove the suspected component (A) from the original failing board.
  (2) Replace the suspected component (A) with a known good component (B) and check if the original board now works properly.
  (3) Mount the suspected component (A) to a known good board and see if the same failure occurs on the good board.

Step 3 is important because it helps us to exclude any possibility that the issue is caused by a systemic issue or the interaction of multiple slightly bad components on a good board.

Hello Charles,

Charles Tsai said:

Based on the above information, the LaunchPad works on both PC1 and PC2. Is that a correct understanding?

I will suppose if you load your custom code to the LaunchPad, it will also work fine on both PC1 and PC2 using either LM flash programmer or dfuprog.exe. Is that also a correct understanding?

Yes, you are right. We are able to load our code on LaunchPad with both PCs.

Charles Tsai said:

Can you do an experiment? In Windows Device Manager, can you uninstall the Stellaris Device Firmware Upgrade device and then reinstall the driver. I wonder if that makes a difference on PC1. 

I tried on PC1, no differences.

Charles Tsai said:

Do you have any custom board that will work on PC1 and PC2? Or you only have one board to test? The reason I ask is because if you have at least one board that works on PC1 and PC2 then you could do a ABA swap test - meaning to swap the MCU on the board that works for PC1 to the board that fails and vice versa. 

The A-B-A Swap Method is a simple cross check test, which can confirm the observed issue is not systemic.

• A-B-A Swap Method
  (1) Remove the suspected component (A) from the original failing board.
  (2) Replace the suspected component (A) with a known good component (B) and check if the original board now works properly.
  (3) Mount the suspected component (A) to a known good board and see if the same failure occurs on the good board.

Step 3 is important because it helps us to exclude any possibility that the issue is caused by a systemic issue or the interaction of multiple slightly bad components on a good board.

We have many boards, but the errors seem to be PC dependent: in other words I see the same behaviour for PC1 and PC2 with every board. As I said previously:

• PC1: not possible to correctly connect and flash the SW on custom boards.
• PC2: possible to connect and flash the SW on custom boards.

Angelo Traina said:

Yes, you are right. We are able to load our code on LaunchPad with both PCs.

Angelo Traina said:

We have many boards, but the errors seem to be PC dependent: in other words I see the same behaviour for PC1 and PC2 with every board. As I said previously:

• PC1: not possible to correctly connect and flash the SW on custom boards.
• PC2: possible to connect and flash the SW on custom boards.

Hi Angelo,

  Based on your above feedback, the summary is the LaunchPad works on PC1 and PC2.  All custom boards fail on PC1 but work on PC2. Is this a fair statement?

  At the moment, I kind of run out of ideas on how to diagnose the problem. Do you have a USB analyzer at your disposal? I was hoping that if you have a USB analyzer then you may be able to decipher any subtle different traffic between PC1 and the board vs. PC2 and the board. 

-Is your board taking power from the USB port or you have a different power source?  

-Perhaps something you can check if PC1 is creating some disturbance/noise to the board vs PC2.

  * Look at the power supply to the board and see if there is any difference when connecting to PC1 vs PC2. 

  * Look at USB0DM and USB0DP signals and compare between when PC1 is connected vs. PC2.

- How many LaunchPads do you have? Is it true that all LaunchPads (if you have more than one) will work on PC1 and PC2?

-Lastly, is it possible to do a ABA swap test? The LaunchPad is working per your experiment on PC1. I really hope you have more than one to spare. Can you swap the MCU on the LaunchPad to one of your custom boards and vice versa. This will really help to understand if the problem traces to the MCU or to the board or still PC related. 

Hi Charles,

Charles Tsai said:

  Based on your above feedback, the summary is the LaunchPad works on PC1 and PC2.  All custom boards fail on PC1 but work on PC2. Is this a fair statement?

Yes, that's correct.

Charles Tsai said:

  At the moment, I kind of run out of ideas on how to diagnose the problem. Do you have a USB analyzer at your disposal? I was hoping that if you have a USB analyzer then you may be able to decipher any subtle different traffic between PC1 and the board vs. PC2 and the board. 

-Is your board taking power from the USB port or you have a different power source?  

-Perhaps something you can check if PC1 is creating some disturbance/noise to the board vs PC2.

  * Look at the power supply to the board and see if there is any difference when connecting to PC1 vs PC2. 

  * Look at USB0DM and USB0DP signals and compare between when PC1 is connected vs. PC2.

Unfortunately I have not a USB analyzer, nevertheless I will check our board and run a comparison on USB signals with the oscilloscope. I will check the 4 different cases: PC1+LaunchPad, PC1+Custom board, PC2+LaunchPad, PC2+Custom board. I will let you know if I find something, please keep me updated if you have any new idea on your side.

Thanks for the advice.

Hi Angelo,

  Do you have any update?

Hello Charles,

Sorry for the late answer, I was waiting some time to be sure that the solution we have found was effective.

After a signal analysis with the oscilloscope, we concluded that our board needed HW fix on USB0DM and USB0DP tracks. After this HW modification the custom board can be flashed with every PC. I believe initially the problem was visible just for some PCs due to different USB HW installed on each of them.

Thank you very much for the support!

Hi Angelo,

does it mean we can consider this issue resolved?

Please let us know

Thanks

Fabio

Hi Fabio,

Yes thanks.

Angelo