• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 80 subscribers
  • Views 1361 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.

Help porting ctpl library to gcc

Clyde Byrd
Prodigy 80 points
Other Parts Discussed in Thread: MSP-EXP430FR5969, MSP430FR5969

Hi all I'm currently trying to port the compute through power loss library for the FRAM boards (Testing on fr5739, 5969, 6989). 

I read in another thread that to port it I'd need to do the following:

"The two components that would need to be ported from the TI compiler to GCC are the the linker files (placing all RAM data into FRAM with the exception of the stack) and the low-level assembly routine. The remainder of the source code is C and should be compatible with GCC."

I thought I had a decent grasp on the assembly file and (after some reading) the linker script, but it seems I'm still having some problems. 

I'm using the 5969 as my testing board at the moment. I'm trying to get the example ctpl_ex4_adc12_b_monitor_msp-exp430fr5969.c code working with the gcc compiler (I'm trying to use the latest TI backed GCC at the moment). 

I tried putting all the .bss section and the .data section in FRAM, but it didn't work out so well for me. I then tried to split the FRAM in to two sections one R/W capable and mapped it sections of memory under .cptl label. I then put all the the variables that should persist in to that section using the attribute directives.

I was able to test that I could R/W to this FRAM section by storing a value and checking it over power cycles, but when trying the full example, the code never seems to restore state properly. It just performs the normal operations.

Any ideas or could someone look at ctpl_low_level.S and msp430fr5969.ld and see if I've done something blatantly wrong?

Their corresponding CCS equivalents are also attached.

Please let me know if I could provide any more information. I've spent a decent amount of time solo debugging and I've reached a near stopping point.

I've attached the files Ive changed and the .asm file I converted to .S @ctpl.zip

  • 0
    TI__Guru**** 206957 points
    Hi Clyde,

    I will try to bring in the CTPL author to comment on this issue, please allow some time for them to review the material and formulate a response.

    Regards,
    Ryan
  • 0 in reply to Ryan Brown1
    Prodigy 80 points

    Hi Ryan, thanks for helping. I've found out the issue.

    For future readers:

    the ctpl_ init function was not being called, because the overriding function name is different for the latest ti-gcc

    In ctpl_pre_init, _system_pre_init or __low_level_init is defined conditionally via the preprocessor.

    The issue is 4.9.0 gcc for msp430 does not use these functions to override the default pre_init functions after the stack init function is called.

    4.9.0 uses crt0.o init functions and usually you can override these with __attribute__((constructor)), but that wasn't working for me.

    I found this that uses some magic apparently (aka the fact that functions in crt are called before main) and I made it work.

    I'm not sure if this is the proper solution so I'll ask another question.

    For users of gcc 4.7.0 or so, you can over you can override them with examples from this link

    4.7.0 uses __low_level_init in memory section init3. as seen in linker maps when you generate them, but you need to specify the memory section via an attribute as seen in the github examples.

  • 0 in reply to Clyde Byrd
    Guru 267910 points

    The ctpl_init() function is buggy; it should #‌‌error out if the compiler is not known.

    Support for __attribute__(constructor) can be disabled with the -minrt option; this is commonly done to save space.

    You have to check all other usages of compiler-specific #‌if's whether they allow for gcc.

  • 0 in reply to Clemens Ladisch
    Prodigy 80 points
    To be fair, it won't compile if you are not using IAR or CCS compiler, it doesn't say explicitly that it's do to an unsupported compiler, but it does error out due to syntax issues of not having a proper function definition. Early on I was under the naive assumption that _ system_pre_init was an overridable function in GCC like CCS and used that name and I paid for that oversight. I will check and see if there are more compiler specific things that could cause issues that I didn't catch yet. Thanks.

**Attention** This is a public forum