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.

TMS320F28069M: Locking MCU using CSM breaks _IQ() macro

Part Number: TMS320F28069M

When using FAST and locking the F28069M MCU using the CSM, all _IQ() macros produce the value 0. By stepping through the disassembly I found the cause.

This happens because the _IQ() macro uses the constant 16777216.0L which is located into Flash, but tries to use it from the FD$$MPY function which is FAST ROM. Since FAST-ROM does not have access to the user protected Flash, the value 0 is used and the _IQ() macro returns value 0.

Edited to add solution:

{

The project was missing the Link Order settings, causing the linker to use FD$$MPY in FAST-ROM instead of linking in the version from rts2800_ml.lib.

}

One solution mentioned in the relevant documentation is to move .econst to unprotected RAM, like RAML7. This moves *all* constants to RAM, which is a waste of RAM. There must be a better solution.

I see two possible solutions;
- Make the linker include an FD$$MPY function in Flash, and ignore the one in FAST ROM for user code
- Selectively move only part of the constants to RAM, instead of all of them

The first solution seems preferable. More general, I would like to tell the linker that it should not use the math functions in FAST-ROM provided by 2806xRevB_FastSpinROMSymbols.lib for code running from protected user Flash. I don't know enough deep linker configuration wizardry to correctly tell the linker what I want it to do. Please help :)

Cheers,

Rob

  • Hi Rob,

    We have assigned the thread to Linker Command File expert. Meanwhile, please take a look at this link which explains the linker command file in details:

    https://software-dl.ti.com/ccs/esd/documents/sdto_cgt_Linker-Command-File-Primer.html

    Thanks & Regards,

    Santosh

  • Hello Santosh,

    I'm afraid your linker command file expert has not picked this up yet. Could you check with them for any progress please?

    Thanks,

    Rob.

  • Hi,

    You may refer to the document Santosh suggested for details.

    For example, to move const from a specific obj from a  specific library - 

    gpioConst
    {
    driverlib.lib<gpio.obj>(.const)
    } > FLASH_BANK0_SEC0

    Without library -

    gpioConst
    {
    gpio.obj(.const)
    } > FLASH_BANK0_SEC0

     

    Regards,

    Veena

  • Hello Veena,

    I have read this document (and more), and did not find a solution for this issue.

    I am familiar with the method to move a section from a library to a specific memory section.

    The constant we would have to move is produced by the _IQ() macro (it's 16777216.0L, 2^24). This value is used in multiple macros in several files, and the compiler/linker puts this into a section called for example ".econst:_$P$T4$5". There are several of these, and the names change. The names seem to be semi-randomly assigned. I will call these 'anonymous sections'. We cannot reliably locate an anonymous section in a specific memory. This solution would also require us to reactively fix whatever is broken, moving a specific constant to unprotected RAM after the code stops working correctly, which is not a reliable situation.

    The solution we prefer is having the linker not use the FD$$MPY in FAST-ROM, but putting a copy of FD$$MPY in Flash. This FD$$MPY would be in protected Flash, and thereby have access to constants in protected flash. To generalize this, we would prefer to never call any of the standard library functions which are included in FAST-ROM (log, exp, FD$$MPY, FS$$MPY, FS$$ADD, ldexp, modf, L$$DIV, frexp etc etc.) because these cannot access constants in protected Flash. These functions (FD$$MPY certainly) get their parameters passed by reference, and it is left up the the FD$$MPY function in FAST-ROM to read the value from protected Flash, which it cannot do.

    We need to tell the linker "Don't use FD$$MPY (etc) from FAST-ROM, but put copies of these in Flash and use those".

    Cheers,

    Rob

  • Hi,

    Have you tried the LOAD/RUN feature, that allows users to copy the code to RAM and run from there?

    I will also check with the compiler experts if there are any other solutions

    Regards,

    Veena

  • Hello Veena,

    Copying the code to protected RAM would not solve the issue, copying it to unprotected RAM would break security. Also, there would be no practical way to decide which code needs to be copied, as any floating point division, multiplication, conversion etc could use one of the functions in FAST-ROM.

    We do not have a way to put FD$$MPY etc in protected Flash (running from unprotected RAM is not required, as protected Flash can access the constants in protected Flash), which seems like the correct solution.

    We need to protect the code, so copying to (unprotected-) RAM is not an option.

    It seems to me that we can't be the first company that tries to protect a F28069 chip, with protected user code that uses the _IQ() macros and thus FD$$MPY. My guess is there is some wonky linker configuration which prefers the FD$$MPY in FAST-ROM over putting another one in user flash. Fair enough, most times you do not need a second copy. But the linker should be aware of the fact that the code in FAST-ROM cannot access constants in protected user Flash memory. I am sure there is a solution for this, but we cannot find it.

    Best regards,

    Rob.

  • Hi Rob,

    I meant moving only the FD$$MPY and other functions you mentioned to RAM.

    Can you share your .map file?

    Regards,

    Veena

  • We have just tested enabling the CSM in proj_lab5b, which works without causing this issue. Even though FD$$MPY is in FAST-ROM and the linker knows this, it still puts a copy in Flash as well, from rts2800_ml.lib. That is how we need this to work. Not a workaround where we keep running into hard to diagnose bugs until we hopefully fixed them all, but a system that normally works.

    We do not need to move anything to RAM. The root cause is that the linker is using functions from FAST-ROM, which do not have access to user-protected-flash. The linker should put a copy of these functions in user-protected-Flash, instead of re-using the ones in FAST-ROM, which are in a different security domain and cannot access the constants located in protected user flash, which are passed by-reference.

    Sharing the map file is not an option, as it contains a lot of proprietary information in function and symbol names.
    the proj_lab5b version automatically places a copy of FD$$MPY in FLASH
    our project for some reason does not, it uses FAST-ROM FD$$MPY instead, causing the problems

    We think these is some configuration issue in our project which causes use of FAST-ROM FD$$MPY instead of putting another copy in Flash.
    What causes the linker to do this?

    Comparing the linker options in Build > C2000 Linker > Summary of flags set, removing the options which are the same between the working proj_lab5b and our problematic project, these are the differences:

    -O3 (-O2 in lab, irrelevant)
    --advice:performance=all (irrelevant)
    --define=F2806xF (irrelevant)
    --gen_func_subsections=on (tested, does not effect fd$$mpy)
    --gen_data_subsections=on (tested, does not effect fd$$mpy)
    --heap_size=0 (irrelevant)
    --stack_size=0x200 (different value, irrelevant)

    In both cases the linker command file does not include any configuration telling the linker to place anything from rts2800_ml.lib into flash specifically.
    The linker command file does not seem a likely cause, as it does not mention either rts2800.lib or 2806xRevB_FastSpinROMSymbols.lib at all.

  • Let me forward this query to the fast library experts

    Regards,

    Veena

  • I was also trying one of the lab projects and see the following in the map file

    mpy and other RTS functions are part of .text and is allocated to specified RAM/Flash location, not ROM.

    Do you see these objs listed in your map file?

    Can you confirm you have "rts2800_ml.lib" added in Linker --library option. (For some reason, I dont find that info in  Summary of flags set)

    Regards,

    Veena

  • Yes, rts2800_ml.lib is in C2000 Linker > File Search Path > Include library file list. It is also the library set in CCS General > Project tab > Runtime support library. (It was the same between the proj_lab5b and our project, I listed only differences)

    As .text ends up in RAM, perhaps you are using a RAM build configuration?

    Does your test-project include 2806xRevB_FastSpinROMSymbols.lib? That library tells the compiler where these functions are located (well, symbols really).

    Here is a bit from my map file (some lines removed)

    You can see e_log2f.c.obj from rts2800_ml.lib ends up in flash. The linker knows how to find that library and how to put the required functions in Flash. It just does not put a copy of the functions in Flash if it knows there is a copy in FAST-ROM.

    FD$$MPY is located at 0x3f81d6, in FAST-ROM, which starts at 0x3f8000 and goes up to 0x3fbxxx or 0x3ffxxx (depending on what you see as FAST-ROM)

    As we think the issue is caused by some mis-configuration of our project, we will compare all other options. So far we have looked at the linker first, but maybe this is a C2000 Compiler setting. There are rather a lot of them, so this will take some time...

    Thanks for diving in this deep with us Slight smile

    Cheers,

    Rob.

  • Hi Rob,

    Yes, I used the ram config. Even in flash config, I see rts2800_ml.lib : fd_mpy28.asm.obj (.text) is part of .text and is assigned to Flash memory, not ROM. Do you not see this obj in the .text section in .map? If not, which section is it part of?

    Regards,

    Veena

  • fd_mpy28.asm is not mentioned in the map file.

    FD$$MPY is listed in GLOBAL SYMBOLS in map file, with the address in FAST-ROM as it's address.

  • Got it;

    The proj_lab5b properties, CCS Build > Link Order tab specifies in what order the linker must process the libraries.

    Our project was missing this setting, and the default order (?) was finding FD$$MPY in FAST-ROM before ever looking in rts2800_ml.lib.

    For future reference, this is what the proper link order looks like (from proj_lab5b):

    We will need to do some testing, but I'm confident this fixes the issue.

    Thanks again!

    Rob.

  • Hi Rob,

    Glad you were able to figure it out and thanks for posting the root cause. 

    Regards,

    Veena