• State Resolved
  • Locked Locked
  • Replies 17 replies
  • Subscribers 33 subscribers
  • Views 2471 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/TM4C1231H6PGE: Debugger doesn't stop at main () unless I set the FLASH base address as 0x00000000

Richard Chen75
Intellectual 550 points
Part Number: TM4C1231H6PGE

Tool/software: Code Composer Studio

Hi all, I have a program where the debugger doesn't stop at main (), it has APP_BASE as 0xA000 in its default linker command file, if I change it to 0x0000, the debugger works as expected and is able to stop at main ().  Does anyone know why? I recall that I was able to debug applications that doesn't start with 0x0000, so I am surprised on why I had to change this for this one.

Thanks

Richard

  • 0
    TI__Guru 72500 points
    Hi Richard,
    The stack pointer and reset vector have to be in the first two locations of flash memory (0x00000000 and 0x00000004). These locations cannot be blank. Perhaps the issue is that you expect a boot loader at address 0x00000000, but it is not there.
  • 0
    Mastermind 8695 points

    What is APP_BASE? I do not see this symbol in my .map file or linker file (.cmd file is the linker correct?).

    I see my main start with the program counter at 0x1F50.

    When I change the configuration not to reset to main, the program counter starts at 0x51BC with is the address of _c_int00 in my .map file.

    It is counter intuitive that code which runs before main is after main. Both start far from 0.

  • 0 in reply to Bob Crosby
    Mastermind 8695 points

    This makes sense when looking at the memory. Address 4 is the address of _c_int00. I can see the PC stating with this address.

  • 0 in reply to Peter Borenstein
    Intellectual 550 points

    Thanks Bob and Peter for the relies. I think that you are right that the case worked for me might have had a boot loader in place so that it appears to be able to run when I debug my application starting from 0xA000. While in this case, I have nothing at the start of flash and that is why the debugger never stop at main () because the control will never be passed over.

    Thanks

    Richard

  • 0 in reply to Peter Borenstein
    Guru 55913 points
    Hi Peter,

    I think what Bob is referring; if you compile your application with APP_BASE=0x00000000 (_ccs.cmd) , the main function should be located there. Unless someone has somehow combined the Serial Boot Loader into the application, unsure that is even possible since the entire vector table changes from SBL into the application based table. Then it becomes more of a challenge to determine where the 8KB boundary of the application starts above SBL, typically 0x00004000.
  • 0 in reply to Genatco
    Guru 55913 points
    This forum web page is messed up not showing last post or even as being resolved and Peter was last post showing until I posted.
  • 0 in reply to Genatco
    Mastermind 8695 points
    Are the TivaWare ROM_ functions also fixed at some address similar to the vector table? Or is the driverlib.lib loading them into a read only address when programmed?
  • 0 in reply to Peter Borenstein
    TI__Guru 72500 points
    The ROM_ functions are at a fixed address in ROM. They use a pointer table at the beginning of the ROM to support compatibility when new revisions of devices are produced with bugs fixed. Between device revisions, if a bug is found in a ROM_ function, then a driver library version of the function should be used. To make this automatic, call the MAP_ version of the function. Then the ROM_ version will be used unless a fixed version of the same function exists in the driver library.
  • 0 in reply to Bob Crosby
    Guru 117855 points

    Bob Crosby said:
    Then the ROM_ version will be used unless a fixed version of the same function exists in the driver library.

    May we ask,  "How the MAP_version - knows or detects - that there is a bug in the ROM_function - and (then) fetches the driver library function, instead?     It is assumed - that some "indicator" MARKS the (specified) driver library (equivalent) function - which prevents that (mirrored) ROM function from being deployed.     Is this close/correct?

    Should this "prove the case" - this may enable a "Quick/Dirty" contrast/compare of Execution - (proper) ROM function vs. Flash...

    Thanks your time & attention.

    [edit]   Dawns that such "Contrast/Compare" of,  "Rom call vs Driver Lib call" - may be easily achieved via, "Use/Non-Use" of  "ROM" - preceding the driverlib function's name.      D'uhh...

    It would still prove of interest to learn, "IF & HOW" the (assumed) Driver Lib function - which is to over-ride that function w/in ROM - is recognized & triggered.      (s'il vous plaît...)

  • 0 in reply to Bob Crosby
    Intellectual 550 points
    Bob, it is good to know that DriverLib contains the same set (or newer) of APIs as ROM, do you know where I can find the implementation of ROM APIs?

    Thanks
    Richard
  • 0 in reply to Bob Crosby
    Guru 55913 points

    Hi Bob,

    Feeling really cheated believing compiled ROM calls added to Tivaware library functions were being copied in EEROM versus being executed from flash memory. Sort of believed the MCU was somehow moving the pointers or the code into EEROM. 

    It must be doing something like that because I made changes to Tivaware GPIO AHB port defines that were missing in the compiled driver library and they work from ROM.  

  • 0 in reply to cb1_mobile
    TI__Guru 72500 points
    Hi CB1,
    Excellent question. I should have made may explanation more complete.

    If a bug is found in a ROM function, that function will be fixed in the next version of the TivaWare driver library. The library includes a header file, rom_map.h. If the ROM function is good, it redefines "MAP_xxxx" to be "ROM_xxx". If the ROM function should be replaced, it defines "MAP_xxx" to be "xxx" which causes the function to be pulled from driverlib.lib and placed in the flash memory.

    A little more detail, the "rom.h" file distributed with TivaWare defines all of the ROM functions that we consider good. To get the benefit of replacing buggy ROM functions automatically with updated driver library functions, use the "MAP_" prefix and include first "rom.h" followed by "rom_map.h". "rom_map.h" actually uses the defines in "rom.h" to determine if the ROM version of the function is good.

    Now to automatically switch all of the ROM based functions to driver library versions of the function, simply comment out the inclusion of "rom.h". The header file "rom_map.h" sees no ROM function names defined so it uses the driver library version of every function that was coded with the MAP_ prefix.

    Now some projects you may not want to update the functions automatically (or more specifically, without your knowledge) when a new version of TivaWare is released. If you use the ROM_ prefix, but include the new version of "rom.h", you will get a link error if a ROM function was deprecated in the new library. Then you can check the release notes to determine why the ROM version was deprecated.
  • 0 in reply to Richard Chen75
    TI__Guru 72500 points
    Hi Richard,
    The source code for all of the valid ROM based functions is included as part of the TivaWare library. For example, the source for ROM_SysCtlPeripheralEnable() is in the file "C:\ti\TivaWare_C_Series-2.1.4.178\driverlib\sysctl.c" starting on line 845.
  • 0 in reply to Genatco
    TI__Guru 72500 points
    Hi BP101,
    A call to a library function with "ROM_" prefix will be executed from ROM. A call to a library function without the "ROM_" or "MAP_" prefix will be loaded into flash memory. A call to a library function with the "MAP_" prefix will be run from ROM unless the ROM version was deprecated in TivaWare. In that case it will be run from flash.

    In your case, the correction of the port defines may have modified the parameters that were passed to the ROM function causing it to then work correctly.
  • 0 in reply to Bob Crosby
    Guru 117855 points

    Greetings Bob,

    In my (very best) Elvis ... "Thank you - thank you VERY Much!" (in this case - my thanks is REAL!)

    Really an, "Above/Beyond" response - well described & detailed - very much appreciated.

    My (assumed) understanding of the "detection/correction mechanism" (i.e. embed w/in the individual (over-riding) driver lib function) was (again) "Off-Mark."      The "rom.h" (and friends) method you provided - proves superior - due to "faster/easier implementation."    (i.e. "One-Stop" Search!)

    Such well thought - "correcting mechanisms" - especially when implemented w/such "User EASE" - prove highly commendable!

    Again thanks for your terrific response - hopefully of benefit to "many."

  • 0 in reply to Bob Crosby
    Guru 55913 points
    Thanks Bob for the in depth analysis.

    Explains why the Snowflake GPIO changes (gpio.c/hw_memmap.h) then allowed access to MCU embedded ROM calls GPIO ports above K. The benefit from making ROM/MAP calls suspect are two fold, reduced flash memory requirement and fewer read cycles on flash memory bit cells especially within SW loops.

    How can we know what the MCU embedded library version might be relative to current Tivaware SW driver library versions?
  • 0 in reply to Bob Crosby
    Intellectual 550 points

    Thank you Bob for the reply. I also liked your reply to cb1, which is very informative.

    Thanks

    Richard