• State Resolved
  • Locked Locked
  • Replies 13 replies
  • Subscribers 30 subscribers
  • Views 1970 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.

Flashing TM4C123GLX with sflash in Linux through ROM Boot loader

Claus Smitt
Prodigy 180 points
Other Parts Discussed in Thread: LMFLASHPROGRAMMER

Hi everyone,

I am currently working on a project which is going to have 3 EK-TMC123GLX Tiva C boards that communicate with an  ARM Linux SBC (single board computer) through SSI (SPI actually). This Linux SBC is also going to be responsible for updating the Tivas' firmware, thus they must be able to run a boot loader in order to get updated.

I decided to call the ROM boot loader from the board's application and update them running the "sflash" program from the Linux SBC.

I first took a look to the sflash program, and realised that it uses the standard serial port interfaces in order to communicate to the boards. Therefore here goes my first question:

1) If I manage to map the Linux board's SPI interface to one of the ports of /dev/ ,  would I be able to communicate with the boards via SPI, specifying this port when y call sflash without modifying it, or should I change something in its source code? (the Tiva has of course ran ROM_UpdateSSI() ).

In order to start testing the firmware updating procedure, I decided to start doing it through the board's virtual serial port that the ICDI provides (updating through UART instead of SSI). I wrote a simple app that flashes the LEDs and calls ROM_UpdateSSI() afterwards.

I flashed this app at address 0x00 with LMFlasher from Windows, through the ICDI and afterwards (when this app is has already called the UART boot loader) I flash this app again, but this time through UART using the COM port that the ICDI enumerates. This way I can flash the app over and over again without any problems.

The LMFlasher config was: Baudrate: 115200; Transfer Size: 60; Auto Baud support: Disabled; Reset MCU after Program: enabled; Program Address: 0x0

2) When I try to do the same with sflash in Linux (which I compiled just issuing "make") the program gets stuck and doesn't update the firmware.

I issued:  ./sflash bin/Program.bin  -c /dev/ttyACM0 -b 115200 -s 60 -p 0x0 -d    Or   ./sflash bin/Program.bin  -c /dev/ttyACM0 -b 115200 -s 60 -p 0x0 -r 0x0 -d


And I get:

Application    : bin/Program.bin
Program Address: 0x0
       COM Port: /dev/ttyACM0
      Baud Rate: 115200
Erasing Flash:


And it gets stuck there, instead of transfer the program.

Have I compiled sflash wrong? Is there something that I missed? does sflash need some modifications in order to work properly? Should the sflash command be different from the ones stated above?


Thanks in advance to everyone.

  • 0
    TI__Guru**** 244400 points
    Hello Claus,

    1. The sflash is for UART Com Port only. The ICDI does not have a SPI port to the target MCU so it would not work even after updating the sflash
    2. When running the application on Linux can you remove the Auto Baud Disable message instead and also connect a scope to the UART TX and RX lines to capture the last good transaction between the Linux Host and the Target MCU.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Prodigy 180 points
    Hi Amit,

    Sorry maybe I didn't clarify that. I do not intend to update the Tivas firmware through ICDI, I just started testing it with the UART. In the future I'll hook up the Tivas to the Linux Host through one of it's SSI interfaces. I read around that libraries such as spidev can map the Linux host's SPI interfaces to standard /dev/ ports, so I intend to use that ports in the sflash command. Will THAT work?

    If that wouldn't work, do you have any recommendation on how to achieve this without coding may own sflash app?

    LMFlash has the option to program the MCU through SSI, is there a Linux version of that feature? can i find the source code of the LMFlasher somewhere or just the code for that part?

    I'll try out measuring RX and TX. By capturing the RX and TX transactions, you mean capture them as I debug the sflash program?

    Thanks in advance,

    best regards,

    Claus
  • 0 in reply to Claus Smitt
    TI__Guru**** 244400 points
    Hello Claus

    Let me clarify the following

    1. The LMFlash does not have the option to program the MCU through SSI.
    2. Remapping the SSI to a COM port would work on the Linux Host but the issue is going to be with the SSI clock requirements and the data read routine which is not there in the sflash as it has been built with the UART async port structure.

    In the past few days there has been mentioned on the forum on a new utility that is close to completion and which shall provide for additional interface of SSI and I2C. The source code would be available for customers to develop the serial boot loader. However the LMFlashProgrammer will always remain as a "non available source code" resource.

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

    Hi Amit,


    Thanks for the quick answer. I guess I took for granted that the LMFlash had an SSI programming option (my mistake, i juast checked).


    Until this new SSI utility is out, I'll perform the updates through UART. It took me a while to make it work because when using the ROM bootloader, UART0 must be used and in the ek bord the Rx pin is hard wired to the debugger Tx pin which is a low impedance output, thus this pin loads any external Tx pin connected to it (aka the Linux Host's Tx).


    In order to solve this, I modified the boot_serial example to use UART1 instead of UART0, and modified boot_demo1 as well to do the same thing. I also modified the boot_demo1 start address to 0x02800 (which is the one configured in the bootloader) and I call the serial bootloader by issuing

    (*((void (*)(void))(*(uint32_t *)0x2c)))();

    Thanks again for the quick replay.

    Regards,

    Claus

  • 0 in reply to Claus Smitt
    TI__Guru**** 244400 points
    Hello Claus,

    Or you could have connected the EXTDBG pin on the LaunchPad to GND which would have tristated the PA0 and PA1 from the ICDI MCU making the same available for the Programmer.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Prodigy 180 points
    Hi Amit,

    Is the EXTDBG pad the one next to the TXD pad? because y just grounded it and retry using the ROM bootloader, and i get the same problem with the low impedance output.

    Is the EXTDBG another pad?

    Regards,

    Claus
  • 0 in reply to Claus Smitt
    TI__Guru**** 244400 points
    Hello Claus

    Yes, that is the same one. Or alternatively you can also switch the Power Selector to use the VBUS of the Main MCU and remove the header shunt jumper to power down the ICDI MCU

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Prodigy 180 points
    Hello Amit,

    No dice :( . I just tried that and still get the transmitted signals from the linux host attenuated due to the low impedance output. Grounding the EXTDBG makes me unable to program the MCU through ICDI, but it doesn't seam to tristate it's outputs.

    If this doesn't work I'll just use the flash BL, but I find this behaviour rather strange though.

    Thanks again for your help.

    Regards,

    Claus
  • 0 in reply to Claus Smitt
    TI__Guru**** 244400 points
    Hello Claus,

    As per the last post suggestion of switching off the ICDI what is the voltage level on the TXD and RXD?

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Prodigy 180 points
    Hi Amit,

    Vrxd = 3.13 V and Vtxd 3.03 V

    Regards,

    Claus
  • 0 in reply to Claus Smitt
    TI__Guru**** 244400 points
    Hello Claus,

    That is strange. I used the Main MCU USB to power the board after switching the selector pin and removing the Header just next to TCK and the Vrxd = 3.294V and Vtxd = 0V

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 27285 points

    Amit Ashara said:
    That is strange. I used the Main MCU USB to power the board after switching the selector pin and removing the Header just next to TCK and the Vrxd = 3.294V and Vtxd = 0V

     Hi Amit, as per Claus reported, I try'd to use Launchpad as programmer and this failed, to use LP as programmer internal TIVA must be disconnected or simply use the connected launchpad, remove all zero ohm jumper then mount a connector to access all pin of programmer, this way it work, using tiva 123 board it fail due to load of processor pin.

     Another way is if Claus is trying to multiplex tx of all board to receiver, this way the simplest solution I can see is a triple input  AND gate between uart of tiva and PC receiver, this if problem is not misunderstood from me.

  • 0 in reply to Roberto Romano
    TI__Guru**** 244400 points
    Hello Roberto

    Did you use a TM4C123 or TM4C129 LP?

    Regards
    Amit