• State Answer Suggested
  • Locked Locked
  • Replies 19 replies
  • Answers 1 answer
  • Subscribers 32 subscribers
  • Views 4013 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Problem with flash using ROM bootloader via FTDI

Pawel Polawski
Prodigy 150 points

Other Parts Discussed in Thread: TM4C1294NCPDT, EK-TM4C1294XL, LMFLASHPROGRAMMER

Hi all,

Let me describe my situation:

I have TM4C1294NCPDT chip on my board. By default fresh device from factory after power up will run bootloader.

It will do that because it detects that flash memory is not programed etc (details in datasheet on page 669 - Boot configuration).

At this stage it is possible to flash device using LM Flash Programmer via Serial UART. I am using build 1613 of this util.

To connect to device I am using FT232R chip witch latest Windows 7 drivers for it, it is visible as virtual COM7 on my system.

I programmer fresh device using UART0 and LM Flash Programmer and there were no problems with it. Also I setup BOOTCFG

register to be able run bootloader during power up by applying low level (GND) on PF2 which I have pulled up to 3V3 via 10k resistor.

Now the fun part begins. After I power up board normally it runs my code, blink diodes and communicate via UART0 (so FTDI chip is working)

with Putty or any other serial console. After I reset board (both power reset or reset button) with applied low level on PF2 it freezes. So i assume

that bootloadder is called according to plan. When I release the button and reset board it works normally so it makes sense.

The problem is when I want to flash board again using LM Flash Programmer and Serial UART option (like I do with fresh device).

I am getting "Establishing communication with target..." message and next error popup:

"Failed to establish communication with the board...

The program using the serial port (UART), the board must be

programmed with the serial flash loader or a properly configured bootloader"

So now my question - What is wrong? I tried to do that with Auto Baud Support enabled and disabled. Result is the same.

I thought that I be able to flash the board because it has bootloader in internal ROM which will listen on UART0.

Or maybe this is problem with FTDI chip (it is strange because it works perfect with normal running board). I tried all of that on

EK-TM4C1294XL and it was working fine. What I am missing? Or this is problem with LM Flash Programmer tool? I tried with build 1606

and situation was the same.

  • 0
    TI__Guru**** 244440 points
    Hello Pawel,

    Let me get it correct first
    1. The first time with a factory erased part the boot loader via UART0 works correctly
    2. The BOOTCFG is configured to detect PF2 with Low Polarity by the application code
    3. Now if you driver PF2 low and reset the device it does not start the UART boot loader?

    If that is the case then can you do the following check

    1. Please send in the value of the BOOTCFG register as read by the application
    2. Please also check that the reserved bit fields are not programmed to 0 in the BOOTCFG register

    The LMFlashProgrammer latest version is 1613.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Prodigy 150 points
    BOOTCFG register readed by application has value: ffffa8fe
    When my firmware starts it turns one of the board LEDs ON. When I start board with PF2 drived low this not happened, LED is off.
    Because of that I assume that bootloader code is executed instead of my code.
    I checked it both with LM Flash Programer build 1613 and the older version 1606 I think.

    Maybe I should use other tool than LM Flash Programmer? In that case what tool? I have also JTAG connector so in worst case
    I will use it but the target was to use internal ROM bootloader to on field firmware updates.
  • 0 in reply to Pawel Polawski
    Prodigy 150 points
    OK, I have some new clues.

    1 ) I removed FTDI chip from my new board and added RX and TX cables directly to processor UART0
    2) I took EK-TM4C1294XL evaluation board which I am able to program usin UART0 and LM Flash Programmer.
    I added goldpin 2.54" connector to TX and RX on X1 connector.
    3) I removed MCU 3V3 jumper from evaluation board to disable second processor power and use only debug processor.
    4) I connected this modified evaluation board to my new boar to work as a USB to UART converter visible under Windows 7
    not as a FTDI but Stellaris VIrtual Serial Port.
    5) I started my new board firmware and it communicates on virtual COM port (both read and write)

    Conclusion: My evaluation board is now works the same way as FTDI (virtual com port).

    Using that setup I tried one more time to flash the device via UART using LM Flash Programmer. It failed on both: auto baud enabled and disabled. One more time I got error described earlier.

    Conclusion: Flash problem is not fault of FTDI chip because serial converter from evaluation board also not works. The same converter works when I am flashing evaluation board via UART.

    So at the moment I was able to flash new processor only for the first time. But when I display BOOTCFG settings while device is running it all looks OK and it is possible to jump to bootloader. But then it looks like bootloader freeze. Maybe some problem with clock source or clock settings? So why I was able to flash it for the firs time? Hmmm, strange.
  • 0 in reply to Pawel Polawski
    TI__Guru**** 244440 points
    Hello Pawel,

    The BOOTCFG value of ffffa8fe indicates that the value has not been committed. The bit-31 must be clear. Since it is not committed then after a reset it will revert to the original value and not go to the boot loader.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Prodigy 150 points
    Now I am confused:/

    I setup the same way my Evaluation Board (low level on PORTF PIN2 trigger ROM bootloader after reset).
    I commited value and in fact it is different than BOOTCFG default value (default PORT is 0x7, my is 0x5, the same with PIN
    default is 0x7 my is 0x5). So in fact register value changed, so why 31st bit not shows that? Take a look at my code bellow:

    void InitBootloader(void)
    {
    // Registers for bootloader selection
    uint32_t reg;

    uint32_t* fmaReg;
    uint32_t* fmdReg;
    uint32_t* fmcReg;
    uint32_t* bootcfgReg;

    fmaReg = (uint32_t*)FLASH_FMA;
    fmdReg = (uint32_t*)FLASH_FMD;
    fmcReg = (uint32_t*)FLASH_FMC;
    bootcfgReg = (uint32_t*)FLASH_BOOTCFG;

    //Read BOOTCFG value
    reg = *bootcfgReg;
    //Clear boot GPIO trigger settings
    reg &= 0xFFFF00FF;
    //Set new settings (based on datasheet):
    //PORTF = 0x5
    //PIN2 = 0x2
    //POL = 0 (low lever trigger)
    //EN = 0 (disable flash checking)
    reg |= 0xA8 << 8;

    *fmaReg = 0x75100000;
    *fmdReg = reg;
    *fmcReg = 0xA4420008;

    UARTprintf("Old BOOTCFG: %x\n", *bootcfgReg);
    UARTprintf("New BOOTCFG: %x\n", reg);
    }

    Output on console (register commited before):
    Old BOOTCFG: ffffa8fe
    New BOOTCFG: ffffa8fe

    Do I make commit operation wrong?
  • 0 in reply to Pawel Polawski
    TI__Guru**** 244440 points
    Hello Pawel,

    OK. Point taken. So can you erase the program code, power cycle the board, just connect the debugger w/o loading a code and check the content of the register?

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Prodigy 150 points
    I do another thing in my evaluation board - I tried to change value from A8 to AA by commit operation:
    Old BOOTCFG: ffffa8fe
    New BOOTCFG: ffffaafe

    And it failed. After power cycle value of the BOOTCFG is still old one - the previously commited. So I cant commit new value
    because I have already commited BOOTCFG before. It make sense. But NW (bit 31) has still value 1, not 0. And you say that after commit
    the 31st bit value should be 0?
  • 0 in reply to Pawel Polawski
    TI__Guru**** 244440 points
    Hello Pawel,

    8 cannot change to A (as this is Flash operation and require erase of the whole device with Unlock operation). When writing the value of the BOOTCFG the user has to make the bit-31 as 0 and then commit. So in this case

    0xFFFFA8FE -> 0x7FFFA8FE

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Prodigy 150 points
    OK, I have new things to share.

    I removed 25MHz crystal oscillator from board. Now when I start it and bush my bootloader button (PF2 to low level)
    it is possible to flash board and bootloader works fine with various baudrate settings.
    But after I flash the device my code is not running due to missing external clock source.

    After I solder 25MHz xtal back to board I cant run bootloader anymore. Board start in bootloader mode but it freezes.
    So in my opinion the problem is that ROM bootloader detect external clock source but from some reason cant use it
    and hangs.

    There are two possible reasons of that:
    - Problem with my 25MHz quartz oscilator (tomorrow I will try other type, manufacturer and value - 16MHz)
    - Problem with handling external clock source by ROM bootloader. Maybe it use the clock but due to prescaler settings
    it cant set specified baudrate speed on UART port and because of that baudrate error LM Flash Programmer cant
    communicate with board? To be clear I have tested it with enabled and disabled auto baudrate detection.

    First thing i will check tomorrow. But I know nothing about internal bootloader implementation and clock handling in it.
    Does anyone know anything about it or have similar experiences?
  • 0 in reply to Pawel Polawski
    TI__Guru**** 244440 points
    Hello Pawel,

    I have used the ROM Boot Loader with the prescribed settings (my last post) on the EK-TM4C1294 with 25Mhz crystal and it has worked. Have you tried the same combination?

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Prodigy 10 points

    Hi,

    I wonder if problem can be with version of Serial Boot Loader is shipped with "bare" chip. Does TI allow to upgrade/change SBL? Maybe evalboard has newer/different SBL than shipped with chip? Is it possible to download binary SBL from TI site?

    regards

    Mikołaj Tutak

  • 0 in reply to user4262989
    TI__Guru**** 244440 points
    Hello Mikolaj,

    The SBL is working all the time for me on the LaunchPads and Internal test board. There is no change to the Serial Boot Loader for Rev 2 and 3 of the Silicon

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Prodigy 150 points

    Another thought from me: in my board RTC clock is missing because I not use it. Both XOSC0 and XOSC1 ar at the moment not connected.

    In table 26-7 from datasheet it is suggested to connect XOSC0 to GND but NC is marked as acceptable practice. Is that can be a source of problem?

    If ROM bootloader checks that pin as a possible clock source? If the ROM bootloader code is open for users or this is closed source firmware?

  • 0 in reply to Pawel Polawski
    Prodigy 150 points
    OK, I removed RTC clock from eval board and it still works fine.
    But I realized one thing:
    - processor on eval board is XM4C1294NCPDT13 44A5F1W G4
    - processor on my board is TM4C1294NCPDT13 4BA6Z1W G4

    Is there any difference in those devices other than name?
  • 0 in reply to Pawel Polawski
    TI__Guru**** 244440 points
    Hello Pawel

    RTC is not the source of the issue. The X marker is for an experimental device (I don't suspect that to the issue either as timings are the last items to be char-ed for production version).

    Can you share with me the code for the Flash based application that will jump back to the boot loader? Also I fail to see why the BOOTCFG prescribed earlier has not been used

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Prodigy 150 points
    I used settings for BOOTCFG we discussed before: 0x7FFFA8FF (boot loader triggered by low state on PF2) - it not fix the situation.
    But I think my friend from lab figure out the problem: RBIAS pin.

    The difference between my prototype board and eval board is that on eval board RBIAS pin is connected to GND via 4k87 1% resistor.
    On my board RBIAS is in NC state. In table 26-7 on page 1821 of TM4C1294 datasheet preferred practice for this pin is NC and acceptable practice is connect to ground the same way as on eval board (4k87 1% resistor).
    After I added that missing resistor ROM boot loader started to working with external crystal oscillator (25MHz). Even if I shortcut this
    RBIAS pin to GND without any resistor boot loader works well.

    Conclusion: To use ROM boot loader with processor using external 25MHz quartz RBIAS pin cant be in NC state. It has to be connected to GND (via 4k87 1% resistor for best results, but shortcut works too) even if documentation tells that NC is "preferred practice".

    I think I know where the problem is. After I changed quartz to 16 MHz I was able to communicate with the board for short period of time. Usually I got error with "Failed to establish communication with the board...". After using that slower quartz I got "Erasing" message so flash process starts but after that communication is lost. I think that when RBIAS is floating in NC state ROM boot loader detect false signals on Ethernet pins and thinks that user will use that interface to flash so it stop listening on rest of the interfaces.

    Again it looks like documentation (datasheet in this case) is not clear. The only place where something similar is mentioned (connection between boot loader and RBIAS pin) is note "a" under table 26-7 on page 1822 of TM4C1294 datasheet. Micro controller optimized for use minimal external components (internal PLL, oscilator, pull-up resistors etc.) and designed to be easy to use without special tools (ROM boot loader) requires specified precise 1% external resistor for run? That is strange to me. What is you opinion?
  • 0 in reply to Pawel Polawski
    TI__Guru**** 244440 points

    Hello Pawel,

    I confirm the issue and is going to be a part of the errata. However having said that I had asked for the same information in my first response

    Amit Ashara said:

    Let me get it correct first

    1. The first time with a factory erased part the boot loader via UART0 works correctly

    2. The BOOTCFG is configured to detect PF2 with Low Polarity by the application code

    3. Now if you driver PF2 low and reset the device it does not start the UART boot loader?

    Having known this earlier would have resolved the issue earlier.

    Regards

    Amit

  • 0 in reply to Amit Ashara
    Prodigy 150 points
    Sorry if in "debugging storm" I miss some you questions, there were a lots of places where something may go wrong - from board design to the software implementation. Now with all this knowledge from past few days I think that working evaluation board schematic is safer knowledge source than datasheet itself:)
  • 0 in reply to Pawel Polawski
    TI__Guru**** 244440 points
    Hello Pawel

    I am used to seeing issues hidden behind other issues, so that is why I try to run some experiments to be able to isolate the issues. This post is a good knowledge post for the forum users.

    Regards
    Amit