TM4C129ENCPDT: dfuprog update failer- random burn failer on diffrent devices.

Amit Blumenfeld said:

The problem: We have a windows application that uses dfuprog.exe (provided from TivaWare_C_Series-2.2.0.295) and on some computers, the same bin file, it fails it update (dfu error -7) while in other computers it works fine, with the same bin file, and the same board.

Hi,

  I have not come across such a reporting. It appears it is computer related. I can't understand and explain why dfuprog.exe would run differently between different computers. 

Amit Blumenfeld said:

In computers where the problem accrues, the specs that we get are matching TM4C123GH6PM despite the board been a TM4c129ENCPDT board.

Can you show perhaps a screenshot on how TM4C123GH6PM is being displayed. I'm not aware dfuprog.exe will show a part number like TM4C123GH6PM  or TM4c129ENCPDT . Having said that, the dfuprog.exe has been out there for many years. This is the first time I'm hearing a reporting as such about problem with lmdfu.dll. I wasn't involved with the development of dfuprog.exe and the dll. Not sure what caused your problem and if it is really a lmdfu.dll problem. 

Amit Blumenfeld said:

This behaviour can also suddenly disappear, and the dfuprog works as expected. 

This is especially weird to hear that the problem can go away or appear on the same computer while working on other computers as you described. 

Amit Blumenfeld said:

Sense we do not have access to the ROM code, we can not investigate why the ROM suddenly returns the wrong specs.

Can you elaborate what has been returned by the ROM code that indicates it is a TM4C123GH6PM and not a TM4C129ENCPDT. How did you conclude that it is the ROM code that returns the wrong specs. 

Amit Blumenfeld said:

- The board is in  ROM_UpdateUSB function before the windows application calls defuprog. With the USB peripheral been the active. The clock speed is 50mhz in that state and additional interrupts are disabled.

Can you also try some experiments?

 - Try to run your existing application on a LaunchPad board instead of your custom board on the computer that shows the problem? Can you repeat the same problem?

- There is a example at C:\ti\TivaWare_C_Series-2.2.0.295\examples\boards\ek-tm4c1294xl\boot_demo_uart_rom that calls ROM_UpdateUSB. Can you run this example on your custom board on the computer that appears to have problem? Can you repeat the same problem?

Hi Charles, 

Charles Tsai said:

Can you show perhaps a screenshot on how TM4C123GH6PM is being displayed. I'm not aware dfuprog.exe will show a part number like TM4C123GH6PM  or TM4c129ENCPDT . Having said that, the dfuprog.exe has been out there for many years. This is the first time I'm hearing a reporting as such about problem with lmdfu.dll. I wasn't involved with the development of dfuprog.exe and the dll. Not sure what caused your problem and if it is really a lmdfu.dll problem. 

As mentioned, to try to find the source of the problem, we modified the base code to print logs. It is indid true that the dfuprog does not provide this information, however with local build you can make the code create logs with additional information. 

Charles Tsai said:

Can you elaborate what has been returned by the ROM code that indicates it is a TM4C123GH6PM and not a TM4C129ENCPDT. How did you conclude that it is the ROM code that returns the wrong specs. 

As I have mentioned, before dfuprog is called, the board calls the function  [ROM_UpdateUSB]. This function is provided by Ti driberlib, and from that moment on, the only thing that can run until reset is code from there. The only thing that communicates, and in general, the only thing that follows DFU format in our program is whatever the function dose there. 

From modifying lmdfu, logs were added to different functions within the burning process. As part of the process, the lmdfu calls the function:[DFUDeviceInfoGet]

This function asks the device (in our case, TM4c129ENCPDT  board) in the dfu format about the flash of the device. Later it uses the information to determine if the bin file can be burrned or not. In case it can't, it return the error code -7. From logs of Invalid computers, the information received from dfudeviceinfoget is as following: 

 [start add:6144] [flash top:262144] [flash block size:1024] [num flash blocks add: 256]

The specs of flash size, block size, and addition to the flash, all matching the specs of TM4C123GH6PM .
meanwhile, the same function, from the same board, from a computer that works returns the following:

[start add:0] [flash top:1048576] [flash block size:16384] [num flash blocks add: 64]

those specs match the flash size, and flash block size of TM4c129ENCPDT, as expected.

This is why i say that my current suspicion is the code in the rom. Given that the dll and dfuprog are the same on both computers, which they were on our test, the problem is the response of the device. As much as I would like to blame windows on it, the function used in lmusb dll to transfer, is very basic, and in wide usage, which puts the most likely suspect as the ROM, or its communication with lmdfu.dll. 

Here is a screenshot of the log: 

Charles Tsai said:

This is especially weird to hear that the problem can go away or appear on the same computer while working on other computers as you described. 

I can't agree with you more, which is why I believe the source of the problem is not the computer itself. 

Charles Tsai said:

Can you also try some experiments?

 - Try to run your existing application on a LaunchPad board instead of your custom board on the computer that shows the problem? Can you repeat the same problem?

- There is a example at C:\ti\TivaWare_C_Series-2.2.0.295\examples\boards\ek-tm4c1294xl\boot_demo_uart_rom that calls ROM_UpdateUSB. Can you run this example on your custom board on the computer that appears to have problem? Can you repeat the same problem?

Sadly, I do not have within my position a lanchpad of TM4c129ENCPDT. Sense we used TM4C123GH6PM before, when we moved to 129 we did not acquire a lunchpad. I do have a TM4c123G lunchpad, however I do not know what the differences between it is and TM4C123GH6PM , nor did I sufficiently tested the TM4C123GH6PM board to tell you that the problem with that board is the same one as TM4c129ENCPDT.

Hi,

Amit Blumenfeld said:

As mentioned, to try to find the source of the problem, we modified the base code to print logs

I'm not even aware there is a source code provided. I'm curious as to where do you find the source code?

Amit Blumenfeld said:

As I have mentioned, before dfuprog is called, the board calls the function  [ROM_UpdateUSB]. This function is provided by Ti driberlib, and from that moment on, the only thing that can run until reset is code from there. The only thing that communicates, and in general, the only thing that follows DFU format in our program is whatever the function dose there. 

From modifying lmdfu, logs were added to different functions within the burning process. As part of the process, the lmdfu calls the function:[DFUDeviceInfoGet]

This function asks the device (in our case, TM4c129ENCPDT  board) in the dfu format about the flash of the device. Later it uses the information to determine if the bin file can be burrned or not. In case it can't, it return the error code -7. From logs of Invalid computers, the information received from dfudeviceinfoget is as following: 

 [start add:6144] [flash top:262144] [flash block size:1024] [num flash blocks add: 256]

The specs of flash size, block size, and addition to the flash, all matching the specs of TM4C123GH6PM .
meanwhile, the same function, from the same board, from a computer that works returns the following:

[start add:0] [flash top:1048576] [flash block size:16384] [num flash blocks add: 64]

those specs match the flash size, and flash block size of TM4c129ENCPDT, as expected.

Thanks for providing this detailed info.  As much as I'd like to help, I really have no idea why the ROM bootloader will provide different information from one occasion (showing as TM4C123GH6PM) to another (TM4C129ENCPDT) on the same board and same computer. 

Can you tell how many boards are acting like this? What is the percentage?

I suppose you have some boards that always work in any computer. Is that correct?

If you have a known good working board that always works on any computer, can you please do a ABA swap test? Swap the MCU in a known good board to the suspected board and swap out the MCU on the suspected board to the known good board. What is the outcome? Will the suspected MCU repeat the same behavior on the known good board? Will the known good MCU continue to work on the suspected board. This ABA swap test is important in my opinion to further isolate the problem.  

Amit Blumenfeld said:

Sadly, I do not have within my position a lanchpad of TM4c129ENCPDT. Sense we used TM4C123GH6PM before, when we moved to 129 we did not acquire a lunchpad. I do have a TM4c123G lunchpad, however I do not know what the differences between it is and TM4C123GH6PM , nor did I sufficiently tested the TM4C123GH6PM board to tell you that the problem with that board is the same one as TM4c129ENCPDT.

If you don't have EK-TM4C1294XL LaunchPad, can you at least run the C:\ti\TivaWare_C_Series-2.2.0.295\examples\boards\ek-tm4c1294xl\boot_demo_uart_rom example on your current board. The example calls ROM_UpdateUSB() to start the ROM bootloader. Do you see the same problem? 

I really hope you can acquire a LaunchPad. 

Hi Charles,

Charles Tsai said:

I'm not even aware there is a source code provided. I'm curious as to where do you find the source code?

You can find the source code in TI website at : https://www.ti.com/tool/SW-TM4C 
It contains all the programs provded abote and more. As far as i am aware, it is nececery to properly compile in ccs. 
Spesificly, code for defuprog and lmusbdll and mldfu can all be found in ti\TivaWare_C_Series-2.2.0.295\tools.

Charles Tsai said:

Can you tell how many boards are acting like this? What is the percentage?

As I have mentioned in the quation posting. The same board that works in one computer, dose not work in other computer, and from our epirance, there is no board that works in all computers once the propblem accures. 
From dusents of board in R&D alone, i can tell you that non of them worked when a computer had the problem, while working fine with a compuer without that problem. 

Charles Tsai said:

If you don't have EK-TM4C1294XL LaunchPad, can you at least run the C:\ti\TivaWare_C_Series-2.2.0.295\examples\boards\ek-tm4c1294xl\boot_demo_uart_rom example on your current board. The example calls ROM_UpdateUSB() to start the ROM bootloader. Do you see the same problem? 

I tried to burn the example after bulding it on a TM4c129ENCPDT as you exmplaned, but it dose not work, and crush in runtime. 

Hi Amit,

Amit Blumenfeld said:

As I have mentioned in the quation posting. The same board that works in one computer, dose not work in other computer, and from our epirance, there is no board that works in all computers once the propblem accures. 
From dusents of board in R&D alone, i can tell you that non of them worked when a computer had the problem, while working fine with a compuer without that problem. 

Sorry, I still really have a hard time to explain and diagnose your problem. This is the first time I have seen a reporting as such. You are saying that once the problem occurs on one specific computer then it is 100% failure rate that all boards will more or less fail on that computer. 

Perhaps, I should ask how many computers in your R&D will see the problem? What is the percentage? 

Another question is if you have at least one board that will works on any computer? Or all boards will fail one of the computers? 

In my last reply, I asked for the ABA swap test. Is this possible to do on your side? This step depends if you have at least one board that is always working on all computers.

Amit Blumenfeld said:

I tried to burn the example after bulding it on a TM4c129ENCPDT as you exmplaned, but it dose not work, and crush in runtime

I gave the wrong example. I was giving you C:\ti\TivaWare_C_Series-2.2.0.295\examples\boards\ek-tm4c1294xl\boot_demo_uart_rom in my last reply. This one is for UART bootloader. I meant to say C:\ti\TivaWare_C_Series-2.2.0.295\examples\boards\ek-tm4c1294xl\boot_demo_usb. This is an example that will call ROM_UpdateUSB to enter the ROM bootloader. 

Hi Charles,

Charles Tsai said:

Sorry, I still really have a hard time to explain and diagnose your problem. This is the first time I have seen a reporting as such. You are saying that once the problem occurs on one specific computer then it is 100% failure rate that all boards will more or less fail on that computer. 

Yes, once the problem occurs, the failure rate is 100% with all the board communicating with that computer. 

Charles Tsai said:

Perhaps, I should ask how many computers in your R&D will see the problem? What is the percentage? 

I am not going to give you the number, but 75% of the computers in R&D have experienced or experiencing the problem right now. Currently, around 20% of the computers experiencing the problem. This is excluding client computers, where we have far less information about.

Charles Tsai said:

Another question is if you have at least one board that will works on any computer? Or all boards will fail one of the computers? 

Amit Blumenfeld said:

As I have mentioned in the quation posting. The same board that works in one computer, dose not work in other computer, and from our epirance, there is no board that works in all computers once the propblem accures. 

Charles Tsai said:

In my last reply, I asked for the ABA swap test. Is this possible to do on your side? This step depends if you have at least one board that is always working on all computers.

There is no such board.

Charles Tsai said:

I gave the wrong example. I was giving you C:\ti\TivaWare_C_Series-2.2.0.295\examples\boards\ek-tm4c1294xl\boot_demo_uart_rom in my last reply. This one is for UART bootloader. I meant to say C:\ti\TivaWare_C_Series-2.2.0.295\examples\boards\ek-tm4c1294xl\boot_demo_usb. This is an example that will call ROM_UpdateUSB to enter the ROM bootloader. 

Tried to run the example on a TM4c129ENCPDT , crushes even more then the previous  example. Perhaps ek-tm4c1294xl specification is too different from TM4c129ENCPDT specification that the memory map is too different. I do not mind to try to run a different code if you have in mind, or to create a code meant for TM4c129ENCPDT that will only activate the boot loader.

As I have mentioned before, according to the logs, the most likely problem is the rom, However I can see why you might suspect it to be winusb.h
Please help me solve the problem, It is a huge headache for us and our customers. If you will give rom.c and its dependencies for compile, we are more then willing to continue the debugging process to find the root cause of the problem. It is a big enough problem for us that dedicating time for it is not an issue.

If you are not willing to give rom.c, then can you give us a compiled version of driverlib.lib with relevant information extraction about that part of the problem so that we can continue with the solving of the problem? Otherwise, and it is the computer problems, as you suspect, can you tell me what the problem with computer is? It is not a problem we can keep living with or tolerate, and if we need to change something in the computers, so be it. 

Amit Blumenfeld said:

Tried to run the example on a TM4c129ENCPDT , crushes even more then the previous  example. Perhaps ek-tm4c1294xl specification is too different from TM4c129ENCPDT specification that the memory map is too different. I do not mind to try to run a different code if you have in mind, or to create a code meant for TM4c129ENCPDT that will only activate the boot loader.

TM4C129EENCPDT and TM4C1294NCPDT are pretty much the same. The only difference is that TM4C129ENCPDT has the AES/DES hardware accelerators. As far as running the USB example, these hardware accelerators do not come into the picture. Their memory map is identical. 

What do you mean by crash?  Can you single step and find out why and where it crashes?

I just ran the example on a EK-TM4C1294XL LaunchPad and it builds and runs fine. After running the example I can see two DFU devices. One is the ICDI DFU and the other is the Mouse with Device Firmware Upgrade which is the example enumerated on the USB Device Port. 

In the Device manager, I also see both DFU. 

If I upgrade with a new firmware, I don't see any error. I must say that I have never run into an issue like yours when I run on my only computer. 

I strongly suggest you resolve your crashing issue as this example is the only reference we can compare with your program. 

Not that I know the root cause of your problem, but to see all your boards not working on most of your computers or only working at one moment and later fail on the same computer is really puzzling to me. This is especially puzzling when you said you have been having this problem for several years.  If there is an issue with the ROM bootloader then I would have expected many people complain on e2e forum. However, it is not the case and you are the first one to report such an issue.  

Can you try perhaps on your home computer? I wonder if you can repeat the same on your home computer?

I really suggest you acquire a LaunchPad. If you can, please run on the LaunchPad and see if you can repeat the same. With the problem you have, any means of tools will be valuable to isolate the problem. 

Do you have a USB analyzer? It will help in analyzing where it fails during enumeration. 

Amit Blumenfeld said:

If you are not willing to give rom.c, then can you give us a compiled version of driverlib.lib with relevant information extraction about that part of the problem so that we can continue with the solving of the problem?

I don't know where to find the rom.c. What is stored in the rom is not just the bootloader but also the entire peripheral driver APIs and other things.  The ROM code is part of the silicon that was released a long time ago, may 10 years ago. The implementation of the ROM-based USB bootloader will be similar if not the same as the flash-based USB bootloader which you can find in C:\ti\TivaWare_C_Series-2.2.0.295\boot_loader\bl_usb.c

Charles Tsai said:

What do you mean by crash?  Can you single step and find out why and where it crashes?

The debugger, along with ccs, crushes at buttonsInit(). Probbly a hardfalt for the board as it seems to constntly boot up (by the lead indication) 

Charles Tsai said:

I really suggest you acquire a LaunchPad. If you can, please run on the LaunchPad and see if you can repeat the same. With the problem you have, any means of tools will be valuable to isolate the problem. 

I will see what i can do on that front

Charles Tsai said:

Do you have a USB analyzer? It will help in analyzing where it fails during enumeration. 

The best i have right now is wireshark, but it's not like the information is not recived. Wireshark will only give the same information as the windows driver will give, so i do not think there is much point to it.

Charles Tsai said:

I don't know where to find the rom.c. What is stored in the rom is not just the bootloader but also the entire peripheral driver APIs and other things.  The ROM code is part of the silicon that was released a long time ago, may 10 years ago. The implementation of the ROM-based USB bootloader will be similar if not the same as the flash-based USB bootloader which you can find in C:\ti\TivaWare_C_Series-2.2.0.295\boot_loader\bl_usb.c

I fear the diffrances must be too big, In BL_USB, the information about block size usses defines, which in that case for the error to accure, it should have been universal on all computers. Sadly looking at bl_sub.c seems to be a deadend.

Charles Tsai said:

If there is an issue with the ROM bootloader then I would have expected many people complain on e2e forum. However, it is not the case and you are the first one to report such an issue.  

I highly doute that you will get many reports. You yourself said that you know that there are problem with some computers, which is what we initly were thinking as well. If we did not go the extra mile to modify the dlls to write logs, i would not have come to the conclution that the computer recive wrong information. It took me a few days to get to that, and I assumes that the soultion we have used so far of "use another computer" is the choosen soultion, as the problem is not the most common out there. 

Charles Tsai said:

I strongly suggest you resolve your crashing issue as this example is the only reference we can compare with your program. 

I have modfiyed the exmaple to prevent it from crushing. After testing it around, the problem still presists within the computer with the error. I will point out that the example also dose not work on computers where the normal program dose manage to update. 

Amit Blumenfeld said:

You yourself said that you know that there are problem with some computers, which is what we initly were thinking as well. If we did not go the extra mile to modify the dlls to write logs, i would not have come to the conclution that the computer recive wrong information.

Hi,

  I never said I know there are existing known cases with DFU problems that will not work on some computers. When did I say that? Perhaps you misunderstand me. The only thing I said is that it is the first time I have come across a problem as such that the USB DFU does not work on all computers as you described, It can fail and pass on some computers randomly. When failed, the ROM bootloader will return a flash size that matches a TM4C123 device rather a TM4C129 device. This is all the description I got from you, not that I have heard from others before. 

Amit Blumenfeld said:

The debugger, along with ccs, crushes at buttonsInit(). Probbly a hardfalt for the board as it seems to constntly boot up (by the lead indication) 

Can you show where you are linking to the buttons.c file? The ButtonsInit() is in C:\ti\TivaWare_C_Series-2.2.0.295\examples\boards\ek-tm4c1294xl\drivers\buttons.c. I want to make sure you are linking to the correct file. 

Can you single step through ButtonsInit() and tell which line is crashing?

How did you run this example? Did you import this example from the latest TivaWare SDK? Or you just copy the source files to one of your existing project and rebuild. I will suggest you create a new CCS workspace and 'import' the example to the workspace. This is to make sure you have the correct build configuration. 

Amit Blumenfeld said:

I will see what i can do on that front

Yes, please. The LaunchPad is low cost. In lieu of the current situation, this is one critical data point to see if you can replicate the problem on the Launchpad. The example C:\ti\TivaWare_C_Series-2.2.0.295\examples\boards\ek-tm4c1294xl\boot_demo_usb runs correctly on the LaunchPad despite it should also run on your custom board but you are saying it is crashing on your side. 

Hi Amit,

  Just one quick thought. If you erase the flash, does the board ever fail to enumerate as a DFU device on any computer? When the flash is erased, meaning there is not a valid application, the ROM boot loader will scan each supported communication interface for a command to download new application firmware.

  If you pull up the device manager and look at the driver info for the Stellaris DFU device property, do you see the same data/version among the different computers?

I'm also curious on the DFU result if you use LM flash programmer rather than dfuprog.exe. Do you see the same issue on the failing computers vs the working computers?

Amit Blumenfeld said:

 [start add:6144] [flash top:262144] [flash block size:1024] [num flash blocks add: 256]

The specs of flash size, block size, and addition to the flash, all matching the specs of TM4C123GH6PM .
meanwhile, the same function, from the same board, from a computer that works returns the following:

[start add:0] [flash top:1048576] [flash block size:16384] [num flash blocks add: 64]

those specs match the flash size, and flash block size of TM4c129ENCPDT, as expected.

Hi Amit,

  I kind of want to revisit your observation about the flash size. I have yet to understand why the flash size is sometimes matching a TM4C123 rather than a TM4C129 device but can you do an experiment?

  Read the SIZE field from the FLASHPP register before you call ROM_UpdateUSB() and dump it out through the UART to a COM port. I hope this will lead us somewhere. You said it will return a size that is equal to 256kB. If that is the case, you would read 0x7F for TM4C123GH6PM as opposed to 0x1FF for TM4C129ENCPDT. 

  Please run this as many times as possible because you said it may sometimes work on a fail computer although it fails on the same computer most of the time. If there is a moment that it does not return 0x1FF then it is a good hint on what is going wrong. However, if you always read 0x1FF but still fail DFU enumeration then it will be another area to investigate. 

Hi Amit,

  Do you have any update?