• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 2 answers
  • Subscribers 84 subscribers
  • Views 462 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.

TMS320F28379D: .TI.ramfunc for API Flash Writing library

vincent liebart
Intellectual 590 points

Part Number: TMS320F28379D
Other Parts Discussed in Thread: SYSCONFIG, C2000WARE

Tool/software:

Hello,

I use the F021_API for writing data in the Flash memory.

The user function I created has to be written and executed in the RAM.

I expected that to place copy table in BINIT section would be enough to copy this function from FLASH to RAM, since c_int00 calls __TI_auto_init, which calls copy_in

That's what someone in this forum explained to me, concerning the CLA.

But, trying to compile my function, the linker asks me for the symbol RamfuncsLoadStart, ....

Why the BINT table is not enough?

Also, If I ask to SysConfig to make cmd file generates this Symbol, I see that the generated symbols are not the right ones: 

So, I have to ask for the right symbols on my own:

Why Does SysConfig not generate the right Symbols ?

Thank you for your help.

Vincent

  • 0
    Prodigy 170 points

    Hi Vincent,

    I recently ran into a similar issue while trying to use the BINIT table to automatically load a memory section. In my case, BINIT worked — but elsewhere in the code, there was a manual call to memcpy() using the linker symbols you're being asked for.

    Here's an example of the code that causes the linker to expect those symbols:

    #ifdef _FLASH
#ifndef CMDTOOL
    //
    // Copy time critical code and flash setup code to RAM. This includes the
    // following functions: InitFlash();
    //
    // The RamfuncsLoadStart, RamfuncsLoadSize, and RamfuncsRunStart symbols
    // are created by the linker. Refer to the device .cmd file.
    //
    memcpy(&RamfuncsRunStart, &RamfuncsLoadStart, (size_t)&RamfuncsLoadSize);
#endif
    //
    // Call Flash Initialization to setup flash waitstates. This function must
    // reside in RAM.
    //
    Flash_initModule(FLASH0CTRL_BASE, FLASH0ECC_BASE, DEVICE_FLASH_WAITSTATES);
#endif


    This memcpy call is likely why the linker is complaining — it expects those symbols to be defined in the linker command file.

    If you're using SysConfig, check the .genlibs file. When --define=CMDTOOL is passed, that #ifndef CMDTOOL block is skipped, and the memcpy is not executed — meaning the symbols aren’t required.

    Hope this helps clarify things!

    Best regards,
    Sebastian

  • 0 in reply to Sebastian Glas
    Intellectual 590 points

    Hello Sebastian,

    Thank you for coming back to me. It's very kind.

    I m quite familiar with the CMDTOOL symbol, since I worked wtith the CLA. And just like in the CLA issue CMDTOOL is defined in the device_cmd.cmd.genlibs

    So, any code subject to the non existence of this symbol is skipped.

    For instance, the CLA skipped code was:

    This code has actually to be skipped since the BINIT table induces the copy from FLASH to RAM before the main function.

    But here:

    - although the BINT table is defined the compiler asks for these symbols (but maybe the symbols are not used for the copy but for something else)

    - the symbols are not those which are defined by SysConfig

    - I did not find the functions which use these symbols. How could I kown that I I had to define them before the compiler returned me an error ?

  • 0 in reply to vincent liebart
    TI__Expert 6545 points

    Hi Vincent,

    Thank you for bringing this up, let me discuss internally and I'll get back to you by tomorrow.

    Kind regards,

    Skyler

  • 0 in reply to Skyler Baumer
    Intellectual 590 points

    Hello. Thank you for coming back to me.

    Waiting for your message, I did some tests:

    1) The parser seems to not recognize the symbol CMDTOOL, but it does exist

    I checked that in the desassembly code: the memcpy in device_int() function is not called

    2) The code written in FLASH is copied into the RAM before the main() function, certainly thanks to the BINT table

    3) Actually, the symbols RamfuncsLoadStart, ... are usefull for an other call to memcpy, in InitSysCtrl() function:

    This copy is not canceled by CMDTOOL existence.

    So, the FLASH code is copied twice in the RAM. Why ?

    And the user has to define the right symbols, because the symbols defined by SysConfig (by the cmd file, generated with SysConfig actually) are not the good one: loadStart_ramfunc instead of RamfuncsLoadStart and so on ...

  • 0 in reply to vincent liebart
    Intellectual 590 points

    edit: actually InitSysCtrl() is not called but jsut defined, and it uses the symbol, that have to be defined. So we define the symbols just to make the compilation OK. I must say that I don't know why F2837xD.SysCtrl.c is included in my project (I just started from a TI example)

  • 0 in reply to vincent liebart
    TI__Expert 8891 points

    Hi Vincent,

    vincent liebart said:
    1) The parser seems to not recognize the symbol CMDTOOL, but it does exist

    I don't think there is an issue with the symbols as it is getting defined.

    I see from your folder structure that you have another cmd file linked to the project.

    What are the current issues that you are facing? 

    Is it possible to zip the project and share so that we can have an analysis?

    Thanks

    Aswin

  • 0 in reply to Aswin P
    Intellectual 590 points

    Hello Aswin,

    Thank you for asking me a archive og my project. You can find it in attachment.

    Aswin P said:
    I see from your folder structure that you have another cmd file linked to the project

    the only CMD file that is active is this one:

    Aswin P said:
    What are the current issues that you are facing? 

    The last issue, I think, is that I am forced to declare symbols in this file, just because they are used in the defined function InitSysCtrl(void) (in F2837xD_SysCtrl.c):

    But it seems that this function is never called.

    Aswin P said:
    I don't think there is an issue with the symbols as it is getting defined.

    In device.c, these lines are not executed:

    This copy is done in the TI_auto_init, because the code which has to be executed in the RAM is described in the binit table

    I put a "ifdef" somewhere else in my code ti checked that CMDTOOL is defined, as suggested by this:

    2025_06_23_TISupport.zip

  • 0 in reply to vincent liebart
    TI__Expert 8891 points

    HI Vincent, 

    Apologies for the late reply, i was OOO for 3 weeks.

    I have gone through the project, but i see the cmd option added in your syscfg file, so are you using the cmd file generated by the tool or the external one?

    If you are using the extenal one, please disable the cmd option from syscfg. If you enable the cmd option then the CMDTOOL macro gets defined, which in turn skips executing the memcpy function.

    Also if you are using bitfields, i suggest you to use the InitSysCtrl function instead of the Device_init function.

    Please have a look at the LED blinky example (Driverlib, non syscfg one) - C2000Ware\driverlib\f2837xd\examples\cpu1\led 

    GPIO toggle example (Bitfield, non syscfg one) - C2000Ware\device_support\f2837xd\examples\cpu1\gpio_toggle\cpu01

    Thanks

    Aswin