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.

F28377S NMI RAM error after OTP flash program

Hi,

I tested writing CSM settings to OTP on a F28377S using the flash API Fapi_issueProgrammingCommand function with flag Fapi_DataOnly. Now, if I cycle the power, the DSP gets stuck in boot rom with a NMI RAM unrecoverable error  -> Address : 0x3FE444.

Do I have this error because I used DataOnly flag when writing to OTP flash memory? During bootup ECC detects an error and hangs there? Is there another possible cause for this? Are there other registers I can check to give you more information on the DSP status?

Any help will be appreciated.

Regards,

  • Hi Simon,

    You need to program the ECC as well along with data in OTP. If not programmed (or programmed incorrectly) then ECC error will cause NMI and execution will never jump to application. Please program the ECC value and that should fix the issue.

    BOOT ROM stores the BOOT status at location 0x2C. You can check the same to see what all errors have been generated.  Please refer section 3.17.1 Boot ROM Health and Status in TRM for more detail on BOOT status.

    Regards,

    Vivek Singh

  • Hi Vivek,

    Later yesterday, I flashed my application including the same data in OTP with JTAG. I guess when doing this, it automatically programs ECC. After that, my DSP was booting. 

    When using the FlashAPI, f I use the flag Fapi_AutoEccGeneration, will it set the ECC correctly? Is it as simple as that?

    Thanks

  • Hi Simon,

    When using the FlashAPI, f I use the flag Fapi_AutoEccGeneration, will it set the ECC correctly? Is it as simple as that?

    Yes, that will program the ECC as well. I'll request our Flash expert to confirm this further.

    Regards,

    Vivek Singh

  • Simon,

    Fapi_AutoEccGeneration mode will calculate ECC for the 64-bits of data that you provide to the program function and ECC gets programmed along with Flash/OTP data.  Any data that is not provided for a given 64-bit aligned memory will be assumed all 1s to calculate the ECC.  Hence, make sure to program 64-bits (aligned on a 64-bit memory) at a time when using Fapi_AutoEccGeneration mode.

    Thanks and regards,
    Vamsi      

  • Thanks for the reply.

    Also, if I want to change the GRABSECT/GRABRAM configuration after I programmed it, is it possible? I try to set more bits to 0 and it always fail.

    Thanks
  • Simon,

    It is not possible to reprogram (some 1s to 0s) an already programmed GRABRAM/GRABSECT OTP field since ECC is already programmed for that location.

    However, you can change the link-pointer in OTP (ECC is not programmed for this location in OTP.  API does not program ECC for this location.) and program GRABRAM/GRABSECT again as you want in a new zone select block.  Check out the section 2.13.1.5 Link Pointer and Zone Select in TRM @ http://www.ti.com/lit/ug/spruhx5c/spruhx5c.pdf

    Thanks and regards,

    Vamsi

  • Hi Vamsi,

    I had started implementing this change. Also, what do you mean by : API does not program ECC for this location. Does it mean, if I use the FlashAPI to write the LinkPointer location, I can't use Fapi_AutoEccGeneration?

    Thanks
  • Simon,

    For link-pointer locations alone, even if you use Fapi_AutoEccGeneration mode, API will treat it as Fapi_DataOnly mode. This is to allow users to program the link-pointer locations multiple times.

    Thanks and regards,
    Vamsi
  • Simon,

    Just to be clear, link Pointer locations do not have ECC feature. That's why there are three link pointer locations in OTP which are compared in hardware to get the correct link pointer. Please go through the DCSM section in TRM to get more detail on this.

    Regards,

    Vivek Singh
  • Hi,

    Yeah I understood that. Thanks.

    I tested the fix to change the location pointer and it worked. I could write new GRABSECT/GRABRAM values. I still get the same error as before though. When I try to erase a section using the flash API, it just doesn't work. If I unlock the CSM before, it works. Is there a register I can check to have more information as to why erasing fails? I only have fsmStatus = 0x410 which tells me there was an error erasing but that's all.

    Thanks
  • Simon,

    The fact that the erase succeeds when you unlock CSM tells that you integrated the Flash API correctly in your application.

    Few things to check on why the erase is failing when the device is secured:

    1) Did you copy the functions in the Fapi_UserDefinedFunctions.c file to ramfuncs that is mapped to a secure location of the same zone which you are trying to erase?

    2) As you might know, we have dual zone security for each flash bank. To prevent the corruption of flash operation initiated from one zone by the code running from other zone, there is a semaphore mechanism implemented using FLSEM register (please refer TRM for the definition of the FLSEM register bits). This semaphore must be grabbed by code running from respective zones to enable Flash operations on Flash sectors allocated to that zones. Can you check whether your application takes care of grabbing this semaphore or not?

    For Zone1, please add following code before doing flash operation-
    DcsmCommonRegs.FLSEM.all = 0xA501; // 0xA502 for Zone2

    3) If the flash sector you are trying to program is part of a secure Zone, then you need to unlock the zone by using correct security passwords and then only program/erase operation can be done. Or you need to have the API code in the same zone as that of the Flash sector that you are trying to erase. Our security expert can confirm this.

    Thanks and regards,
    Vamsi
  • Hi Vamsi,

    Do I have to write to FLSEM before every Flash API function call or can I do it only once? 

    Thanks

  • Simon,

    Once the SEM field is initialized for a particular zone, it will remain for that zone until the code running from that zone initializes the SEM field to a value of 00b. As long as the semaphore is claimed by the code running from the zone on which the Flash operations are targeted, you don't have to initialize the FLSEM register before every flash API function call.

    Thanks and regards,
    Vamsi