• State
  • Locked Locked
  • Replies 12 replies
  • Subscribers 33 subscribers
  • Views 2689 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.

CCS/TM4C123GH6PM: Integrating tivaware bootloader to existing application

Bruno Saraiva
Guru 13040 points
Part Number: TM4C123GH6PM
Other Parts Discussed in Thread: EK-TM4C129EXL

Tool/software: Code Composer Studio

Fellows,

My colleague tried to integrate the Tivaware bootloader to his application, but got error messages such as the ones below when compiling:

configPkg/linker.cmd", line 147: warning #10096-D: specified address lies outside memory map
error #10264: DEFAULT memory range overlaps existing memory range FLASH
error #10264: DEFAULT memory range overlaps existing memory range SRAM

And then he called me for help "assuming I'm the bootloader expert"... I'm not - but I can surely look it up!!!

I checked the spmu301d.pdf manual, but while it is quite comprehensive about the API, it does not seem to show how to integrate it to an existing project... Any hints as how to handle the .cmd configurations properly, or guidance towards the proper document?

Regards

Bruno

  • 0
    Guru 27665 points
    You're looking for some sort of link and locate command. Usually the memory map is specified in a file but sometimes via command line. I would have thought the bootloader examples would contain the files to at least use as templates.

    While the flash should obviously not overlap, at least some of the SRAM potentially can.

    Any chance your colleague is trying to link as single application? That would complicate the process.

    Robert
  • 0 in reply to Robert Adsett
    Guru 13040 points
    Hi Robert,
    I'll download his project tomorrow and take a better look. Apparently, that's what was happening: the intention of putting together the bootloader and the application as a single block. That's how we do in our own "complicated" bootloader solution.
    I had not realized, but it seems that the general sequence for the Tivaware bootloader is:
    1- Create a very simple project for the bootloader, configuring whatever hw requirements apply to the board
    2- Upload it to a blank target via CCS or whatever IDE is used.
    3- Create the application "almost as if it were not for a bootloader", except that it must be compiled offset. Generate the .bin file.
    4- With the board running the uploader doing "nothing", use LMFlash to transfer the application's bin file to the board.
    Is that correct?
  • 0 in reply to Bruno Saraiva
    Guru 27665 points
    I don't know if that's correct but it's what I would expect. They are normally separate if for no other reason tan you don't want to reload the bootloader when updating the application.

    It's fairly easy to merge the resulting binaries if you want a single binary for factory programming.

    Robert
  • 0 in reply to Bruno Saraiva
    TI__Guru**** 191206 points
    Hi Bruno,
    Yes, this what the TivaWare bootloader examples will do.
  • 0 in reply to Robert Adsett
    Guru 13040 points
    Robert,

    I was able to test the bootloader example programs, and their are indeed simple and easy to understand.

    A few caveats here that can be avoided by other readers:
    - Compiling the standard boot_serial example generates two weird warnings to which I have not found explanations (posted that separately on the CCS forum).
    - When sending the update firmware via LMFlash, remember to type in the correct offset location.
    - Both boot_demo1 and boot_demo2 blink the led at the same rate - it did suggest to me that the attempt of updating the code had failed, for I assumed a different blink rate would be the "proof of concept". So anyone trying it should change the blinking rate on demo2 to feel happier!

    My colleague will be using a separate bootloader. I did not compile his project because his projects definitions are for a different compiler, and I won't bother to find/install it now... So I still don't have the real explanation for the "memory overlapping" messages of the first post, but if something new comes up I'll update here.

    Bruno
  • 0 in reply to Charles Tsai
    Guru 13040 points
    Thanks, Charles!
    I was later able to confirm that, by working with the boot_serial, boot_demo1 and boot_demo2 set of examples.
    Just missing the explanation for the overlap memory range message... Found another thread for that, and we will check it.
    Bruno
  • 0 in reply to Bruno Saraiva
    Guru 117855 points

    May my small group commend you Bruno - for "Sharing the detail of your effort" - in the hope of, "passing value to others."

    It would "improve reader comprehension" if those "weird warnings" could be listed here. (rather than diverting "ALL" readers - to another site - as a "few minutes of your time (now) - SAVES "thousands of lost minutes" by ALL of your future readers.)     (not to hate me - I'm trying to "ease/speed" others' efforts)

    Blinking at a separate rate is a good suggestion - as would blinking an entirely different Led - or simply toggling multiple (different) GPIOs - which connect to an "off board" (cobbled) "forest" of Leds.    A 7-segment Led provides an "eased handling" of multiple Leds (even when patterns are not numeric) - as well.

    Absent your neat post - and possibly of value - is your description of, "Which Bootloader example programs you used" - and recommend.   I'm not a "big fan" of such bootloaders - yet recall that there are "multiple means of launching" the bootloader - and such may impact "follow-on reader" success...

  • 0 in reply to cb1_mobile
    Guru 13040 points

    cb1,

    Sure, I could have made it more clear.

    The set of examples are:

    - boot_serial (the small project that does nothing but getting the target ready to receive firmware via UART0)

    - boot_demo1 (a simple demonstration program that blinks a led, but also diverts execution into the bootloader area when a switch is pressed)

    - boot_demo2 (similar)

    They are all available in the tivaware examples folder, particularly for the /boards/ek-tm4c129exl set of examples.

    The weird warning were:

    Neither of these 2 macros were found anywhere on the E2E forums this morning.

    Regards

    Bruno

  • 0 in reply to Bruno Saraiva
    Guru 117855 points

    Thank you - much appreciated.
    Perhaps those w/"insider knowledge" can provide the means to, "free the bootloader code examples" from such (unexplained, yet concerning) warnings...

    Note that via PM (moments ago) I've updated you via "outsider knowledge."   (hopefully - "warning free.")

  • 0 in reply to cb1_mobile
    Guru 13040 points

    Just got a reply regarding the mysterious warnings:

    "You should not get those warnings.  This is a bug in the assembler.  I can reproduce the problem.  I filed CODEGEN-3843 in the SDOWP system to have this investigated. You can avoid the warnings by disabling ULP advisor.  In CCS, right-click the name of the project and choose Show Build Settings.  Then use the screen shot below."

    (Project properties -> Build -> ARM Compiler -> ULP Advisor -> uncheck all)

    I guess we can consider the thread replied now. Kind of a "sum of":

    - Robert Adsett pointing out that two separate projects are actually used.
    - Further tests with the example files over launchpad boards, and associated hints
    -  helping on the CCS side of it

    Slainte!

    Bruno

  • 0 in reply to Bruno Saraiva
    Guru 55913 points

    Hi Bruno,

    The memory overlap error can be a killer to a TI-RTOS configuration or other application compile and difficult to resolve. A nice tool exists by clicking on CCS view/other, selecting Memory allocation icon. Takes 1 compile to propagate info into it, then the green/yellow bars indicate used buffers, heap memory sections, INT vectors etc... Graphical layout makes it all seems more clear  if  ever configuration messes up the physical address space of INT vector tables.

  • 0 in reply to Bruno Saraiva
    Guru 27665 points
    Well done and good hints to others on the LEDs

    Robert