TM4C1294NCPDT: LM Flash Programmer - Unable to establish connection or synchronize baud rate

Hi,

  Based on what I see from your screenshots, I suppose you are using the ROM bootloader, correct? I just tried it myself. 

  - First I have the flash fully erased. This is important. If flash is not erased then the ROM bootloader will assume the application is present and just jumps to the application. The ROM bootloader will look at the stack pointer and reset vector at address locations 0x0 and 0x4. If these are non-F's values, then the bootloader jumps to the application.

  - I use the below the manual configuration which is pretty much the same as yours. Of course, my COM port will be different from yours. 

  - I use the ROM bootloader to load a simple blinky example and it loads successfully and I can see the LED blink. 

  - ROM bootloader only works for UART0 and no other UART ports. If you are trying to use other UARTx ports, it will not work. You will need to use flash-based bootlaoder instead where you can configure the specified UARTx port for serial bootloading. 

- Can you use LM flash programmer on the LaunchPad with a erased MCU? Can you repeat the same issue on LaunchPad? LaunchPad has the built-in onboard ICDI debug probe that can also enumerate as a COM port. It is not FDTI. I want to know if this is a FTDI driver issue. 

Hi Charles, 

Thanks for your response. I think I must not have been clear in my initial post. This software works with this product we are developing on all my colleague's computers, but not mine for some reason that I am hoping you can help me identify.

I did not do the development on it, so I am not completely sure, but I believe it is a flash-based bootloader. I do not have a LaunchPad to try this on. Is there anything else we can do to determine if it is an FTDI driver issue?

Deborah Curtis said:

I did not do the development on it, so I am not completely sure, but I believe it is a flash-based bootloader.

I'm confused. If you are using the flash-based bootloader that means the bootloader itself resides at 0x0. In your screenshot, you are loading the application firmware to 0x0. Are you not overwriting the bootloader? Below is from your image.

If you are using a flash-based bootloader then the application must start at a higher address such as 0x4000 with the address aligned to a multiple of 1024 bytes. Please refer to the flash-based bootloader examples at C:\ti\TivaWare_C_Series-2.2.0.295\examples\boards\ek-tm4c1294xl\boot_serial and an simple application that will be loaded by the bootloader through the UART interface. Look at bl_config.h file and see that application is specified for 0x4000 as the starting address.  It is possible to overwrite the bootloader if you must specify APP_START_ADDRESS for 0x0. But is that what you really want? Maybe you want to check with your colleagues to confirm. 

The example application can be found at C:\ti\TivaWare_C_Series-2.2.0.295\examples\boards\ek-tm4c1294xl\boot_demo1. In this bootloading example, the boot_serial project is the bootloader that will first be loaded through JTAG to address 0x0. Once the bootloader is running, it will load the example application boot_demo1 from UART0 interface. Why don't you try this example first? Can you replicate the same problem running the example? This is a proven example and it should work out of the box. To run this example:

1. Load boot_serial to MCU using JTAG.

2. Reset the device.

3. In LM flash programmer select UART interface. For flash bootloader, you need to disable auto-baud rate. See below. 

4. In the Program tab, select boot_demo1.bin file and specify 4000 as the program address. Hit Program button. You should see the download complete. I just tried it myself without any issue. 

Ok, I could be wrong about the flash bootloader / rom bootloader. I know the settings are the same on my screenshots as what my colleagues are using successfully. I will try your suggestion when I am back in the office tomorrow.

I got this result: 

Hi,

  Can you check through CCS memory browser window from address 0x0? Do you have the flash bootloader residing at 0x0? If you have an empty flash or you already have an application that is residing at 0x0 then it will not work. I will suggest you first do a complete erase of the flash. As I outlined earlier for the instructions, load the flash-bootloader to 0x0 using JTAG. You might have a custom flash bootloader but I will suggest you try the stock flash bootloader first and get it to work. If the stock bootloader also produces the same error then I can only think of some driver or computer issue since your colleagues have them working with the same setup.  

What kind of driver or computer issue would cause an error like this?

Please try what was suggest first. If it works then the problem is solved. If you follow the instructions exactly as I outlined using the stock examples and still have the same problem then we can investigate what could have caused your issue. Actually, I have not seen a problem like yours given that the steps are followed. 

Is your board different from your colleagues?

Are you using a flash bootloader or ROM bootloader? You haven't answered my question. Your screenshot shows you are trying to load your application to 0x0 which will overwrite the flash-bootloader if you are really using flash-based bootloader. Is that what you really want?

Which UART port are you using? If you want to use ROM bootloader then the only UART port will work is UART0? Check which FTDI USB to UART adapter you are connecting to.

Let's suppose you are using the ROM bootloader. Do you have any other communication ports that are connected to your board? The ROM bootloader does not know which communication port you want to boot from. Therefore, it will scan through all the available comm ports for booting. If it finds that Ethernet is connected or SPI is connected then it tries to boot from there if there are any valid commands. Can this be your problem? Refer to bootloader user's guide for details. 

I literally took my entire set-up over to my colleague's computer, put the same settings on their LM flash programmer, and ran it without an issue. If you say that the flash bootloader will not work at 0x0, then we must be using the ROM bootloader. My SW person is currently on vacation (as are the other colleagues who might know), so I can not ask her which bootloader we use.

Can you repeat the booting again on your colleague's computer? If no, then it must be the ROM bootloader. The ROM bootloader will immediately jump to the application if it finds that the application is already resident at 0x0. 

It is possible to overwite the flash-bootlader at 0x0 but I find this almost never used by customers. In the flash bootloader there is the ENABLE_BL_UPDATE flag that can be enabled to overwrite bootloader itself. 

//*****************************************************************************
//
// Enables updates to the boot loader. Updating the boot loader is an unsafe
// operation since it is not fully fault tolerant (losing power to the device
// part way through could result in the boot loader no longer being present in
// flash).
//
// Depends on: None
// Exclusive of: None
// Requires: None
//
//*****************************************************************************
//#define ENABLE_BL_UPDATE

Another possibility is that your application, while residing at 0x0 but scan for bootloading command from UART0. After receiving a valid command, it jumps to the ROM bootloader by calling ROM_UpdateUART().

I've spent the last hour trying to connect with CCS to read the memory and can not get it to work either. I made sure I erased the chip and then I re-ran through the boot_demo1 procedure listed above again to make sure I didn't miss anything. I am putting boot_serial.bin onto the device using JFlash Lite. Is that ok or do I need to do something through CCS? If so, I'll need some help connecting. 

Unfortunately, the colleague whose computer I used the other day is working from home today and I can not try again.

Deborah Curtis said:

I am putting boot_serial.bin onto the device using JFlash Lite. Is that ok or do I need to do something through CCS?

If you can successfully load the boot_serial.bin through JFlash then you don't need to use CCS. Having said that, what I'm asking you to try is flash-based bootloader since I don't know for sure if your colleagues are using ROM bootloader or Flash bootloader.  

I successfully loaded the boot_serial.bin through JFlash, but got the result shown above (error: failed to establish connection)

Deborah Curtis said:

I successfully loaded the boot_serial.bin through JFlash, but got the result shown above (error: failed to establish connection)

If you take this board with which boot_serial.bin is loaded through JFlash and run LM flash programmer on your colleague's computer then it will work, correct? In another, it is only your computer that is having the problem, correct?

If you are doing identical things but only your computer is having problem with the UART interface then I will suggest you use the scope or logic analyzer to capture the UARTTX and UARTRX waveforms. Compare between the waveforms captured when running on your colleague's computer vs running on your computer. There must be some subtle differences. 

Yes, it is only my computer that is having a problem.

Ok, I can try and set something up to capture the waveforms. 

In the meantime, I am able to communicate to the device through the same connection if i use a different program (docklight). Wouldn't this indicate it is a problem with my computer using LM flash programmer and not a problem with the UART interface?

Deborah Curtis said:

In the meantime, I am able to communicate to the device through the same connection if i use a different program (docklight). Wouldn't this indicate it is a problem with my computer using LM flash programmer and not a problem with the UART interface?

Can you try a simple hello example from C:\ti\TivaWare_C_Series-2.2.0.295\examples\boards\ek-tm4c1294xl\hello? I don't know which UART instance you are using so you might need to modify the hello example for whichever UART interface you want to use. If you get the hello example working then it means that UART interface is good and your FTDI UART to USB adapter connecting to that UART interface is also working. The only thing left is LM Flash Programmer. However, I don't know why LM Flash Programmer would act differently between your computer and your colleagues. 

Have you tried every USB port on your computer and they all have the same problem?

Can you reinstall LM Flash Programmer? Will that make a difference?

Deborah Curtis said:

Ok, I can try and set something up to capture the waveforms. 

Yes, this will be the best way to find out. 

Ok, my colleague is back in the office who wrote the firmware. She says that we use the ROM bootloader (preinstalled by TI), we use UART0 interface and we don't erase full flash before flashing with LM Flash because we set Boot Configuration (BOOTCFG register) to a specific GPIO that we use to enter ROM bootloader. 

I have not been able to capture the waveforms yet.

Hi,

Deborah Curtis said:

, we use UART0 interface and we don't erase full flash before flashing with LM Flash because we set Boot Configuration (BOOTCFG register

This means that you need to assert whatever the specified GPIO pin to enter the boot mode. Did you do that?

A heads up,  I'm out of office until 8/3 and I will not be able to answer questions in depth until I come back. 

Hi Deborah,

Deborah Curtis said:

I tried a third USB to RS485 converter and got it to work with LM Flash Programmer on my computer.

Glad that your problem is somehow resolved. However, I don't know why this particular USB to RS485 will work vs other converters you have. LM flash programmer has no knowledge what type of converter is connected. If you really want to know why other converters don't work then you will need to compare the scope waveforms. I think there must be some subtle differences between the different converters and perhaps that subtle differences are enough to cause either the MCU side or LM to misinterpret the data. 

Deborah Curtis said:

I tried a third USB to RS485 converter and got it to work with LM Flash Programmer on my computer. What would cause the programmer to work with some converters and not others?

Are you using a 2 wire half-duplex RS485 connection?

If so, perhaps the difference is how LM Flash Programmer interacts with the USB to RS485 converters to control the direction of the RS485 bus.