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.

TMS320F28035: Writing to FLASHB - program crashes

Part Number: TMS320F28035
Other Parts Discussed in Thread: C2000WARE

Hello,

A new requirement for our product is that a copy of the parameters (default for specific device with calibration info) be stored in FLASHB.

This will be done once, in production. All of the information is saved in external flash - this is just a preventive measure if the external flash gets corrupted.

FLASHB is empty and will not be loaded when burning new FW.

I took existing code and added in 1 line of code - and the program stopped working. There is room in FLASHC for more code and also in RAML0.

 Flash2803x_Erase(SECTORB, &FlashStatus);

The code does not work. I've compared the *.map files and *.hex files before and after the code was included - and they are very very similar.

I call the external WD of the device before and after the Flash_Erase, though I'd love to be able to call it during the writing within the actual function.

I try debugging, but cannot enter the Flash_Erase function, and the FW gets "stuck" and doesn't "step over" the function.

Any ideas?

Thanks,

Mechi

  • I realized that the library wasn't included in the project, though I assume it was linked. Anyway, I placed the Flash2803x_API_V100.lib in the project directory, and moved the lines of code further on in the code.

    The device works for a few minutes until the code is reached.

    I stepped into the assembly code and found that an Interrupt is called and not handled. 

    After stepping over the lines in the assembly, the last line called is in Fl28x_EnterCmdMode() - and then the crash for the not-handled Interrupt.

    I'd appreciate any ideas how I can correct this.

    How do I correctly erase and then burn data into FLASHB? Do I have to stop all background functions and Interrupts?

    Thanks,

    Mechi

  • Mechi,

    One of the main rules for programming/erasing/calling the flash API is that the code itself cannot be running from the flash. Another one, that you have hinted at, is that during these specific erase/program/depletion API calls, these cannot be interrupted. 

    I'm attaching the Flash API QuickStart Guide that is in C2000Ware C:\ti\c2000\C2000Ware_4_00_00_00\libraries\flash_api\f2802x\docs, it goes through the above plus other care abouts and how to link the ROM APIs into your project.

    Additionally, there is a flash callback function we have implemented to help address things like watchdog function calls during the flashing process.  That is addressed in the guide as well.

    Let me know if you have any follow ups after you take a look.

    Best,

    MatthewFlash2802x_API_Quickstart.pdf

  • Thanks.

    I previously downloaded an older version - but it's for a different family. We're using F28035.

    I assume that the concepts are the same, so I'll study it.

    the code itself cannot be running from the flash

    Does this apply even if no code is in FLASHB and I want it to be for DATA?

  • Mechi,

    Sorry for sending the F2802x vs the F2803x, the flash technology is the same so the document should still apply.  The F2803x should have a version as well in the similar relative path as the one I mentioned above.

    To your last question, yes even if only used for data, code must be executing from RAM to program the flash.

    Best,

    Matthew

  • I was able to run the example program even after using the linker cmd file that I use for my main FW project.

    I'm still having trouble including even a single call to Flash_Erase from within the device's code.

    Some more clarifications:

    1. I assume that the Flash API functions themselves are in SARAM - because I don't see them and I can't put them into "ramfuncs", as I do with the other functions in the example:

    #pragma CODE_SECTION(Example_CallFlashAPI,"ramfuncs");

    2. From the Guide -

     >>>   The Flash API saves the state of INTM and DBGM before and restores them after time critical code segments.

    I assume this means that if I call the API routines, I don't have to call _Fl28x_DisableInt: and _Fl28x_RestoreInt:

  • Mechi,

    Since this device has a limited amount of SRAM we placed the Flash APIs inside the BROM so that the user doesn't have to take up that space with a fixed library.  If you want to utilize the API in ROM you need to link the 2803x_FlashAPI_BootROMSymbols.lib into your project.

    If you use the API routines then you don't need to worry about the DisableInt/RestoreInt actions, they will be handled in the API.

    Best,
    Matthew

  • Thanks for all of the advice and pointing me in the right direction.

    After reading the manual and following the pointers, I was successful in writing to FLASHB.

    I see the data in FLASHB using the Memory Browser - and it is still there after power down.

    Now I'm looking into how to read FLASHB - seems easy - reading-back-from-internal-flash-of-tms320f28335

    Thanks again!

  • Mechi,

    Glad to hear you were successful with the flashing project. 

    Are you looking to export the data in FlashB external to the device to either a PC or other IC?  We have something called DSS scripting that can interface with CCS at the API level to automate functions like this w/o having CCS open(would still need the JTAG connected).  https://software-dl.ti.com/ccs/esd/training/workshop/ccsv9/dss_fundamentals_workshop.html

    Let me know if there is some other aspects I can help out with here.

    Best,

    Matthew

  • At the moment I'm fine.