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: What will happen if I program flash from the program located in flash?

Part Number: TMS320F28379D

Hi,

because of a software evolution I unintentionally move flash programming FAPI functions from RAM to FLASH, by removing a line in linker script that locates the API in RAM:

.TI.ramfunc: { -l F021_API_F2837xD_FPU32.lib }
   LOAD = FLASHC, PAGE = 0
   RUN = RAMD0_1, PAGE = 0,
   LOAD_START(_RamfuncsLoadStart),
   LOAD_SIZE(_RamfuncsLoadSize),
   LOAD_END(_RamfuncsLoadEnd),
   RUN_START(_RamfuncsRunStart),
   RUN_SIZE(_RamfuncsRunSize),
   RUN_END(_RamfuncsRunEnd),
   table(BINIT)

I only left following:

  .TI.ramfunc: LOAD = FLASHI
       RUN = RAMD0_1,
       table(BINIT)

Althrough the FAPI is in flash I saw that flash programming was performed successfully.

Here are the conditions:

  1. data is programmed in sector C,
  2. programmed flash locations are blank (only FFs),
  3. Main FAPI code is located in another flash sector (e.g. sector G)
  4. three minor functions are still in RAM (i.e.: Fapi_setupEepromSectorEnable, Fapi_setupBankSectorEnable, Fapi_serviceWathcdogTimer that are in Fapi_UserDefinedFunctions.c).
  5. my loop that waits for end of programming is in RAM: while(Fapi_checkFsmForReady() == Fapi_Status_FsmBusy);
  6. the program does not execute erase command only program-with-auto-ecc
  7. the interrupts are disabled
  8. CPU is secured by DCSM (all flash sectors, RAMD, RAMLS are secured)

I would like to ask:

  1. if it will work all the time with my conditions, or there is a risk that sometimes goes wrong?
  2. if it goes wrong, what errors can be expected:
    1. NMI,
    2. incorrect data programmed in flash
    3. or data programmed in another locations (or even sectors)?

I prefer not to change my code if it works, so I am looking for confirmation of that.

Regards,

Piotr Romaniuk

  • Piotr,

    I need to check with some other on this, but as you said in general we don't support programming flash while running from flash.  The reason is that during programmation there are some internal nodes that are altered in order to program that could impact the readback of the flash.  I am doubtful I will be able to give you a solid green light on the current setup, as we likely didn't do any validation around different scenarios.

    Since you are only programming and not erasing, let me see if there is some de-risking due to this. I'll try and reply back tomm with more info.

    Best,

    Matthew

  • Piotr,

    I checked back with the team on this one, and this will need to be fixed in you project/linker.  Across all conditions there are cases where the program operation may fail.

    Your failure summary is correct, I believe the risk is confined to the sector in use, however.

    Just a note, since this is the dual core device; the flash belonging to each CPU is a physically different bank so if we were programming CPU2 flash, we could be executing from CPU1 flash and vice/versa.  I believe that CPU1 also has ability to program CPU2 flash.  I don't think this applies/is helpful here but wanted to mention it.

    Best,

    Matthew

  • Thank you for the response.

    Just a note, since this is the dual core device; the flash belonging to each CPU is a physically different bank so if we were programming CPU2 flash, we could be executing from CPU1 flash and vice/versa.  I believe that CPU1 also has ability to program CPU2 flash.  I don't think this applies/is helpful here but wanted to mention it.

    There are separated buses for each CPU and corresponding FLASH, I am afraid there is no access across two parts.

    Regards,
    Piotr Romaniuk

  • Matthew,

    Can you contact me with someone who knows the architecture of this processor in details? 
    I wish to discuss the topis with him.

    Regards,
    Piotr Romaniuk

  • Piotr,

    I am asked to review the last answer regarding programming CPU2's bank from CPU1.

    CPU1 can't program CPU2's flash bank.

    CPU2 can't program CPU1's flash bank.

    Each CPU has a dedicated flash wrapper and it can erase/program it's dedicated bank.

    Please let me know if you have any other questions.

    Thanks and regards,
    Vamsi

  • Hi Vamsi,

    Thank you for additional confirmation. Yes, I know these facts - it was just an idea proposed by Matthew.

    I am rather interested in operation of the flash and cpu in my specific conditions.
    I saw that it generally worked, that I was very surpprised.
    I need to undertand the details.

    Regards,

    Piotr Romaniuk

  • Hi Piotr,

    There can be undefined specification issues in this context.

    For example, this errata will become applicable to your application situation now: https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1320238/faq-tms320f28003x-tms320f28004x-flash-api-usage-advisory-errata 

    Similarly, there can be other remote and/or race conditions involved for which we can't confine the failure outputs to what you outlined.  

    We suggest to execute the flash API from RAM in this device.

    Thanks and regards,
    Vamsi

  • Thank you Vamsi,

    Regards,

    Piotr Romaniuk