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.

TMS570 writing to OTP with F021 API

Other Parts Discussed in Thread: TMS570LS1224, UNIFLASH, SEGGER

Greetings;

I am having difficulty using the F021 API to write to the customer OTP section 0xF0000000 in order to lock a TMS570 device using the AJSM.  We are using a TMS570LS1224 on our custom device (i.e. not a TI SDK) running FreeRTOS.

I am trying to write the four word (128-bit) hex string, let's say it's four lines of 0x44444444 (my actual security key is obviously different and mindful of the 1s and 0s of the visible key).  I am setting privilege mode using prvRaisePrivilege().

I am using the following API calls:

    uint32_t tempAjsm[4] = { 0x44444444, 0x44444444, 0x44444444, 0x44444444 };

    fapi_status = Fapi_initializeFlashBanks( main_clock_mhz );
    fapi_status = Fapi_enableBanksForOtpWrite(0xFFU);
    fapi_status = Fapi_issueProgrammingCommand(
            (uint32_t *)(0xF0000000),
            (uint8_t *)((uint32_t)(&tempAjsm[0])),
            16, NULL, 0, Fapi_AutoEccGeneration);
    fapi_status = Fapi_disableBanksForOtpWrite();

In between each operation I am checking if (FAPI_CHECK_FSM_READY_BUSY == Fapi_Status_FsmReady) before proceeding.


All of the API calls come back Fapi_Status_Success, but the memory location at 0xF0000000 to 0xF000000C still shows the original "visible key" (0xEFFDFFFF etc.).


My assumption is that I'm doing something wrong, but per the documentation I can't determine what would still need to be done. 

Do I need to call Fapi_setActiveFlashBank()?  The enumerated type it takes in as a parameter only lists Fapi_FlashBank0 through Fapi_FlashBank7, none of the OTPs.  

Thanks in advance,

Joe Shidle

joe.shidle@deltamobile.com

  • As an alternative, is there example code using the F021 to program 0xF0000000 for AJSM?
  • Hi Joe,

    I'm looking in to your query will get back to you shortly.
  • Hi Joe,

    Yes, you do need to call Fapi_setActiveFlashBank. The Customer OTP region is also mapped to Banks.

    In this case, 0xF0000000 is mapped to Bank0.

    Set Bank0 to active by calling the Fapi_setActiveFlashBank(Fapi_FlashBank0) before enabling the Bank for OTP write in your sequence.

    This should resolve your issue.

    Thanks,

    Siddharth

  • Siddharth, thank you for the response.

    I added a call to Fapi_setActiveFlashBank(Fapi_FlashBank0) between Fapi_initializeFlashBanks() and Fapi_enableBanksForOtpWrite().

    It appears that the system halts at undefEntry in sys_intvecs.asm, if I step through the code this happens during the Fapi_setActiveFlashBank(Fapi_FlashBank0) call.

    I have disabled interrupts with portDISABLE_INTERRUPTS() at the same time that I assert privileged mode, before the FAPI calls so I don't think it's a rogue interrupt on my end.

    It looks like the BANK field of the Flash Module Access Control register (FMAC) is set to bank 7 (0x7) prior to the call to Fapi_setActiveFlashBank() and set properly to bank 0 (0x0) after it halts inside Fapi_setActiveFlashBank(). So the bank is getting set properly.

    Any additional help would be appreciated.
  • Hi Joe,

    Can you clarify the following queries?

    1. Are you configuring the MPU ? The Fapi_setActiveFlashBank API accesses the TI OTP region and this region should not be under MPU protection.

    2. What is the system frequency and wait state configuration ? The wait states have to be configured correctly before calling any Flash API.

    3. Is the Fapi_setActiveFlashBank function executed from Bank0? If so, You will have to execute this function from RAM.

    Best Regards,

    Siddharth

  • Hi Joe,

    Please see the attached CCS Project, this shows how the AJSM key can be programmed with CCS or UniFlash.
    In this example I have basically created a const array which holds the new AJSM code and ensured that it will be liked to the right location in the flash memory along with the correct ECC.

    Please note, that if you use this to flash your device this will lock you out from JTAG access, as desired ;)

    0363.AJSM.zip

    Best Regards,
    Christian


  • Siddharth, thank you for the response.  My answers follow:

    Siddharth Deshpande said:

    Hi Joe,

    Can you clarify the following queries?

    1. Are you configuring the MPU ? The Fapi_setActiveFlashBank API accesses the TI OTP region and this region should not be under MPU protection.

    I am calling prvMpuDisable(), yes.  Let me know if that is sufficient, or if there is some better method for disabling MPU protection.

    Siddharth Deshpande said:

    2. What is the system frequency and wait state configuration ? The wait states have to be configured correctly before calling any Flash API.


    We're running at 160MHz.  In the FRDCNTL register I have it set to 0x00000311 so we have RWAIT set to 3 with address setup and pipeline enabled.

    Siddharth Deshpande said:

    3. Is the Fapi_setActiveFlashBank function executed from Bank0? If so, You will have to execute this function from RAM.

    That makes some sense.  Do you have some example code of functions running out of RAM on the TMS570?

    Thanks again for your response,

    Joe Shidle

  • Christian, thank you for the response.

    While your suggestion is interesting, it may not be feasible with our current factory setup in the long term. We are using SEGGER J-Link and J-Flash ARM utility which itself does not appear to support programming of flash areas outside of the normal flash bank sectors. We have encountered this issue in the past for other projects, which is one of the reasons I wish to use the Flash F021 API to program the AJSM during run-time.

    I was not able to find any indication that UniFlash is compatible with the SEGGER J-Link Plus programming pod. Do you know if there is TI support for this HW?

    Thanks in advance,
    Joe Shidle
  • Hi Joe,

    I'm not aware about the capabilities of the SEGGER flash utility. However, Bank 7 and OTP programming support do sound to me like this is something which is commonly used during both development and production. Maybe they are willing to implement this... Again, I have no experience how responsive SEGGER is when it come to implementing "new" features.

    We do have beta support for J-Link for CCS 5.0, please see here: 

    I actually tried this in the past and it worked for me.

    SEGGER them self do write on their homepage that J-Link is supported in CCS: 

    However they don't write which version of the IDE does support their emulators and I guess they meant the CCS 5 Beta support.
    So in summary, yes there is limited J-Link support in CCS (5), but it doesn't seem that this is meant for production.

    EDIT1: At least they are writing you should contact them if some support for TI is missing :)

    Best Regards,
    Christian

  • Hi Joe,

    Running functions out of RAM can be achieved pretty easily with our Tool chain.

    Our Linker does support so called copy tables and allows to specify separate Load and Runtime addresses for certain symbols/functions.

    The challenge is to identify the functions which needs to be copied to the RAM and to save and reuse as much RAM as possible. In the following post I have copied an extract from a fairly complex Linker command file which is meant to be used along with the F021 Flash API. It features the use of Groups and Unions to reuse parts of the RAM and thus save the amount of RAM needed for the Flash API.

    The prototypes which are needed to handle the Copy Tables are in the file cpy_tbl.h which is part of our Runtime Library.

    Attached is an example project for the RM48 MCU which shows how the Flash API could be copied into and executed out of the RAM. The magic happens in the sys_link.cmd Linker Command File and the main.c. One understood it should be fairly easy to port it to TMS570LS12x and translate the concept for programming the OTP.

    However, to my opinion the cleaner way is to program the AJSM key at the end of your production with an offline programmer. This will save you a lot of headache. Less code in your safety relevant software, no dealing with the Flash API and copying it into the RAM.

    Best Regards,
    Christian

    6371.F021 API Test.zip

  • Thank you for the responses, Christian.

    The SEGGER J-Link works well with the TMS570 and CCS. The issue seems to be support for SEGGER's binary flash utility that would be used to program a hex file in the factory.

    I'll spend some time working with the RAM example you provided. Thanks again for your help.

    Regards,
    Joe Shidle
  • Hi Joe,

    What I think I didn't wrote in my original post about Segger and CCS was, that if the J-Link works well with CCS than it most likely will also work with our standalone flash utility UniFlash, as both uses the same underlying frame work for the emulator/target access.

    So you got the RAM example running on your device?

    Best Regards,
    Christian