• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 33 subscribers
  • Views 1108 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TM4C129ENCPDT: Trouble Using ROM Calls for TivaWare

Luiz Felipe K Evaristo
Intellectual 310 points
Part Number: TM4C129ENCPDT
Other Parts Discussed in Thread: CODECOMPOSER, TM4C1294NCPDT, TM4C123AH6PM

Hello,

I have built a project using TivaWare 2.1.4, and been calling the APIs from the flash. However, as I need more flash space, I was trying to change to ROM calls (I discovered this exists recently). 

When I changed the API calls from (example) GPIOPinADC(...) to ROM_GPIOPinADC(...) I get "unresolved symbols remain" error in the compiler, for ALL the APIs.

I did include "driverlib/rom.h" and tried to "#define TARGET_IS_TM4C129_RA2", but that didn't work either.

How can I fix this?

  • 0
    Guru 27665 points
    I don't use the ROM calls myself. It would help your erstwhile helpers though if you let us know what compiler you were using.

    I suspect that if you check your map file you will find that the TIVAWare calls do not take much of your memory. In other words this step will not give very much extra room to grow.

    Robert
  • 0 in reply to Robert Adsett
    Intellectual 310 points
    I was using CodeComposer v6...
  • 0 in reply to Luiz Felipe K Evaristo
    TI__Guru 72500 points

    I suggest you add these two header files to your program:

    #include "driverlib/rom.h"
#include "driverlib/rom_map.h"

    Then I use the "MAP_" prefix instead of "ROM_". What that does is it equates to the ROM_ prefix if it is defined in rom.h, but to the function name without a prefix if it is not. That way, if a ROM based function was fixed and replaced in the TivaWare library, the new function will be put in flash and used. If there are no corrections, the ROM based function will be used.

    Example:

        //
    // Configure the system frequency.
    //
    g_ui32SysClock = MAP_SysCtlClockFreqSet((SYSCTL_XTAL_25MHZ |
                                             SYSCTL_OSC_MAIN | SYSCTL_USE_PLL |
                                             SYSCTL_CFG_VCO_480), 120000000);

  • 0 in reply to Bob Crosby
    Intellectual 310 points
    thanks Bob,

    I have seen the "MAP" prefix as usable, but a part of the Flash will be used by the APIs still, right?
  • 0
    Guru 13040 points
    Things required:

    Pre-define the symbols in the project configuration:

    TARGET_IS_TM4C129_RA0 or TARGET_IS_TM4C123_RB1
    PART_TM4C1294NCPDT or PART_TM4C123AH6PM (use actual p/n)

    (if I'm not mistaken, the second symbol is already enough in more recent versions of Tivaware)

    Add the headers:

    #include "driverlib/rom.h"
    #include "driverlib/rom_map.h"

    But as Bob mentioned, MAP_ is a safer bet instead of ROM_.

    And as Robert mentioned, a well structured program does not require too many Tivaware calls, for these tend to reside in your own libraries later, and should not take too much space... Even then, optimization should be able to reduce the flash storage needed for such repeated pieces of code, if you choose "optimize for size" as opposed to speed.

    Bruno
  • 0 in reply to Bruno Saraiva
    Guru 117855 points

    While "steering code to ROM" (appears) to offer "much" - there ARE "impacting calling overheads" - which diminish such, "Flash Size reduction."    (much like vendor's "hint" of "MCU Security" - a "peek beneath the covers" - proves less than thrilling...)

    Are you really, "bumping against Flash max?"      As firm/I often note - perhaps "unique code functions" may be "broadened" - so that they may "rise in occurrence" - yet reduce code size due to their (repeated) use.  (i.e. "re-use")    (Note - you don't want to "degrade" vital functions - you must survey for "high usage general functions" which are prime candidates for such "consolidation.")     Maybe!    ("Every" application IS different - nothing prevents your "quick/dirty" experimentation - and compare/contrast of size under varying implementations...)