This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

LM Flash Programmer **ERROR** Failed to establish Communication with the board! - Ignoring ACK packet

Other Parts Discussed in Thread: TM4C1294NCPDT

I am using proprietary hardware with a TM4C1294NCPDT running on a 25 MHz crystal and using UART0. I have built the Bootloader, which runs without crashing. When I invoke LM Flash with the appropriate configuration (image attached), the message " **ERROR** Failed to establish Communication with the board!" appears (image attached).  I checked the RS485 communication with a scope and see that for the initial PING command, the hardware/firmware responds with an ACK package ("00" "CC") - image attached.  

I know that the UART transmit/receive works, because I can query and view command/response pairs in a TeraTerm terminal window.

Questions:

1. What is the time interval required by LM Flash Programmer between the PING command and the response? Not sure if I'm responding too fast or not fast enough.

2. What is the sequence of commands that the LM Flash Programmer sends? The PING command is obvious, but what is next?

And yes, I've searched through the forums, but most of the questions are either getting the UART on the TM4C129x to work (which it does on my board) or issues once the initial communication is established. If I've missed a thread, I welcome being pointed to it, but please be respectful. I've worked with MCU's for many years and sometimes I just need some guidance.

  • Hello Evelyn,

    The following application note describes the communication protocol for the serial boot loader.

    www.ti.com/.../spma074.pdf

    In the scope plot which is the UTX and which is URX pin from TM4C129x device.

    Also since you have mentioned that it is a custom board using TM4C1294NCPDT and a 25Mhz crystal, can you confirm that the RBIAS pin is connected via a 4.87K resistor to GND?

    Regards
    Amit
  • Thank you for the quick reply.

    I do have access to the indicated pdf, but while it mentions a timeout, the actual period is not quantified. The scope traces are truncated for space constraints, which means they are not to scale. The MCU responded as quickly as possible (within 18 usec) and then with a 1 mSec delay. Neither resulted in further communication with LM Flash.

    In the scope trace, the cyan colored trace with the bus breakout labeled "RS232(Rx)" is the MCU's receive line. Alternatively, the yellow trace with the breakout line labeled "RS-232(Tx)" is the MCU's transmit line. From both the breakout traces and the scope traces I read that the PC (LM Flash Programmer) transmits <03><20><20> and the MCU receives it and transmits <00><CC> in response. This is as expected, however, LM Flash does not continue, which I conclude means it sees something incorrectly.

    There are several pull downs on the proprietary circuit, but the implemented transceiver does not have a pin labeled RBIAS. What does this refer to? 

    Regards,

    Evelyn

  • Hello Evelyn

    What is connected to Pin number 59 of TM4C1294NCPDT?

    Can you please get a scope plot of UART RX and TX on the Digital Side? Also did you try with the button "Disable Auto Baud Support" unchecked.

    Regards
    Amit
  • There are two hardware designs experiencing this problem with the bootloader.
    Design 1: Does not implement Ethernet and pin 59 is left as a NC (preferred practice according to the data sheet).
    Design 2: Implements Ethernet and pin 59 is connected through a 4.87-kΩ resistor (1% precision) for Ethernet PHY (preferred practice according to the data sheet).

    Connecting to the digital side of the RX/TX (at the PC side) is problematic, but I will try.

    Unchecking "Disable Auto Baud Support" causes the same timeout as the bootloader is not built with the AutoBaud feature enabled. Since I can communicate with a variety of terminal programs and the scope can breakout the commands, I do not believe it's a baud rate issue.

    Regards,
    Evelyn
  • Hello Evelyn,

    Design-1 may run into an issue very soon, due to a known issue (please see errata document) when leaving Pun 59 as NC on the TM4C1294NCPDT

    I would like to look at the RX/TX on the micro side and not the PC side.

    As this is a custom flash based boot loader, I would like to know what changes have been done from the original boot loader?

    Regards
    Amit
  • I had gone through the errata - can you point me to the actual document and not just the general TM4C129NCPDT folder?

    I'm sorry, Amit, I misunderstood the scope question. The trace images are of RX/TX from the micro side.

    No changes have been made to the original boot loader except for enabling/disabling the transceiver.

    Regards,
    Evelyn
  • Hello Evelyn,

    The errata is a general errata. The errata number is ETH#03

    The trace image for the TX does not look correct

    1. It is Low during Idle time. The UART TX is alwasy high during Idle time
    2. The logic level 0 in the scope plot for TX is offset which means that the low voltage is above GND.

    Regards
    Amit
  • Never mind; I found the document: www.ti.com/.../spmz850 I will pass this on to the hardware engineers.

    Also, I found that the RS485 conversion cable was creating / transmitting a NULL ('00') when the transceiver was switched from RX to TX and vice versa. It was not seen on the MCU side, which is why it was missed. It was only when examining the character stream with a binary read capability via TeraTerm that it was discovered. Once the control code for the transceiver was set to full duplex, LM Flash programs the MCU. The downloaded code isn't executing yet, but that's the next hurdle.

    Thank you for the support.

    Regards,
    Evelyn
  • Hello Evelyn,

    Can you share the first two words of the application image?

    Regards
    Amit
  • Cleaned up a few more details in the Application and now the bootloader / application pair works just fine.

    The first line of bytes in the application is:
    A8 2C 00 20 3D EB 00 00 31 D3 00 00 4F D3 00 00

    Regards,
    Evelyn
  • Hello Evelyn,

    Great.

    Regards
    Amit