TM4C129ENCPDT: LM Flash Programmer **ERROR** Failed to establish Communication with the board!

The images you attempted to attach did not work. Can you save them as .png and then use this button to insert them in your reply?

I am using proprietary hardware with TM4C129ENCPDT running on a 12 MHz crystal and using UART0 for programming using LM Flash Programmer – Build 1613. Default ROM boot loader is used. I don’t use any custom boot loader. When I try to program using LM Flash Programmer with the below configuration, I get the error **ERROR**: Failed to establish communication with the board. I tried with different baud rates and not successful

After that if the device is programmed using LM Flash (by disabling the Auto Baud Support), the programming is successful.

Can we know the reason for this issue?

 Ettickkan

It appears that the autobaud sequence is not working. I don't know the reason. The units that don't work, do they always fail to respond to LM Flash Programmer autobaud sequence, or only some of the time? You mentioned you tried several baud rates, which baud rates did you try? Did you reset the device between each attempt? Have you looked at the UART TX pin with a scope or logic analyzer to see if the device is trying to send an acknowledge, but at the wrong baud rate?

Dear Bob Crosby

Thanks for your reply.

Yes. The units which do not work, always fail to respond to LM Flash programmer auto baud sequence. At least we had tried more than 10 times in the same device. Also we ensured power off and on for every attempt we tried. We have tried in more than 10 such devices in the Filed and observed the same behavior.

We tried with the Baud Rate range from 1200 Baud to 115200 Baud Rate with Auto Baud Rate enabled (no tick mark in the Disable Auto Baud Support) and resetting the device on every attempt (by Power-Off and then on). Not successful.

We are not able to check UART TX pin with a scope or logic analyzer as these units are installed in a machine in customer place. From remote, we are trying to update the software.

We are able to update other devices using the same programming set up (Same LAPTOP, LM Flash with Auto Baud Sequence and same USB-to-Serial Converters). As I mentioned already some devices (around 30% out of few hundreds) we are not able to upgrade with auto baud sequence.

Do you see any reason for such behavior.

Regards

Ettickkan

So these are not blank new devices? I assume that you have code in the devices and that code then calls the function ROM_UpdateUART(). When calling the ROM bootloader from existing code, the autobaud sequence is not run. The application code must initialize UART0 (setting the baud rate) and disable interrupts before calling the ROM bootloader.

Please describe in more detail what the existing firmware does when you try to do a firmware update.

Device is not blank.

But We make the device to enter into boot loader mode by hardware signal, then LM Flash is used to update the software. Hence our application is not running during this time and ROM_UpdateUART() is not called by our code.

The device enters into boot loader mode by hardware method. ie Reset the device by keeping PH3 low.  PH3 is configured to enable the boot loader at device RESET. EN bit is configured in BOOTCFG to enable boot loader entry by GPIO input

Also Hardware is designed to enter boot loader mode using UART0

BOOTCFG is configured once during our initial production time with below code

uint32_t bootcfg;

bootcfg = FLASH_BOOTCFG_R;

FLASH_FMD_R = (bootcfg & 0xFFFF00EC) | 0xEC12;

We are sure the device enters into ROM Boot loader mode and our application is not running during that time. That is the reason, the same device responds with ACK (0x00, 0xCC) when we use terminal software to send Auto Baud Sequence (0x55,0x55).

Please let me know if you need more details.

Thanks for your support

Regards

Ettickkan

Thank you, That helps me understand your system much better. I do not have a good explanation of why the 0xAA 0xAA from LMFLASH Programmer does not properly autobaud some devices while the same characters from a terminal emulator work. How do you reset the device? Is it by power cycle or by asserting a low on the RST- pin? Is the UART0 RX pin (PA0) being held high by the time RST- is released? The autobaud is done by generating interrupts on both rising and falling edges on PA0. The times of 18 edges are collected and the pulse widths are compared for determining the baud rate. Noise on PA0 could cause an issue.