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.

Creating valid bin file and flashing



Code Composer: 6.1.2

Compiler: GNU v4.8.4 (Linaro)

Target: Tiva C - TM4C123G LaunchPad

Problem (TLDR): Creating a valid *.bin file and programming it with LM Flash Programmer for the uartecho_EK_TM4C123GXL_GNU_TivaTM4C123GH6PM example project.

I've imported the uartecho project for the TI RTOS.  I've put a lot of my application code on top of that example, but now I want to program my board so it can run stand-alone (separate from the debugger).  The first problem I had was the initial creation of the *bin file.  I read a lot about how to create one in post commands and massaged that to get it working.  Pro-tip, some of those binaries only exist on your system if you have the TI ARM compilers installed too, even though the example uses the Linaro compiler and not the TI ARM compiler.

Now that I have a binary, the LM Flash programming tool says that it can't access the bin file.  Similarly to what was discussed in the following post, my bin files are always 524K no matter what I do in terms of optimization so I think that the RAM/ROM model of linking may have something to do with it.  That being said, the Linaro compiler does not offer all the handy configuration options that the TI ARM compiler does, so simply changing the environment model (RAM/ROM) is not as straight forward as checking a box.

Come on... Someone must have wanted to take an example project out of the prison of debugging and actually program their board with it.  Why is it so hard?  Can someone point me in the right direction for taking a simple example project (using the Linaro compiler) from source, to bin file and through to flashing it on the board.  We can't debug forever! Eventually we'll want to actually deploy our work, right?

  • Mark Taylor said:
    Similarly to what was discussed in the following post, my bin files are always 524K no matter what I do in terms of optimization

    The large size of the .bin file for SYS/BIOS projects is explained in this forum post. Could you please try the workaround suggested there of marking the ".vtable" section as NOLOAD in the linker script, and let us know if that helps? 

  • My bin file went from 524,289KB to 55KB!  To clarify exactly what I did for anyone else that finds this post in the future:

    1.) Open your <project>.lds file

    2.) Find the following section:

        .vtable (_vtable_base_address) : AT (_vtable_base_address) {
            KEEP (*(.vtable))
        } > REGION_DATA

    3.) Change it to this: 

        .vtable (_vtable_base_address) (NOLOAD) : {
            KEEP (*(.vtable))
        } > REGION_DATA

    4.) Clean and rebuild.

    NOTE: I haven't tried programming this on my board yet.  I'm am away from it at the moment, but I will check back after I test it out.  

    As an aside, to get my project to build the bin file in the first place, I went into my project settings inserted this into my Post Build steps:

    1.) Show advanced settings -> C/C++ Build -> Settings -> Build Steps -> Post-build steps:

         "${CCS_INSTALL_ROOT}/utils/tiobj2bin/tiobj2bin.bat" "${BuildArtifactFileName}" "${BuildArtifactFileBaseName}.bin"

    2.) CCS Build -> GNU Compiler -> Debugging -> {deselect Generate debug information}

    3.) CCS Build -> GNU Compiler -> Optimization -> {select Optimize for space rather than speed}

    4.) Open up C:\ti\ccsv6\utils\tiobj2bin\tiobj2bin.bat and edit as follows:

       4a.)  Locate "setlocal" (around line 38).

        4b.) Append PATH so the rest of the batch file can locate target binaries:

               "set PATH=%PATH%;C:\ti\ccsv6\tools\compiler\ti-cgt-arm_5.2.7\bin;C:\ti\ccsv6\utils\tiobj2bin"

        4c.) Around line 56... Start removing references to the old ofd and hex executables. I'm not targetting anything but Tiva, so this is okay...

            Take this: 

    set ofdcmd=ofd470
    if not "%~3" == "" set ofdcmd=%3
    set hexcmd=hex470
    if not "%~4" == "" set hexcmd=%4
    set mkhexcmd=mkhex4bin
    if not "%~5" == "" set mkhexcmd=%5

            And change it to this:

    set ofdcmd=armofd
    if not "%~3" == "" set ofdcmd=%3
    set hexcmd=armhex
    if not "%~4" == "" set hexcmd=%4
    set mkhexcmd=mkhex4bin
    if not "%~5" == "" set mkhexcmd=%5
    4d.) Around line 100, take this:
    call :make_exe_work %ofdcmd% ofd470 armofd
    set ofdcmd=%final_cmd%
    call :make_exe_work %hexcmd% hex470 armhex
    set hexcmd=%final_cmd%
            And change it to this:
    set ofdcmd=armofd
    set hexcmd=armhex

  • OK, so LM Flash programmer does successfully program the device and verifies correctly against the bin file. Upon disconnecting the device from the programmer and powering it, the program does not start. I know this because the first thing the device should do is blink a status LED upon being powered.

    What do I do now?
  • To solve this problem, I started over with the TI-tools based TI-RTOS uartecho project and copying my changes over to it. I repeated the steps above for creating the binary, however the size of the binary was fine, so modifying the linker script was not required. LM Flash Programmer wrote the binary onto the board and it started running by itself as expected. So, lesson learned: Do not use the GNU examples.
  • Mark Taylor said:
    Upon disconnecting the device from the programmer and powering it, the program does not start. I know this because the first thing the device should do is blink a status LED upon being powered.

    When using the GNU tools, one possible reason for that is semihosting being enabled - see GNU examples for EK-TM4C123GXL fail to start unless debugger connected