Flash programming via SCI via an already executing application

Boy you grabbed this one fast ... !  Hi, Trey.  I read your posts every day and save many of them.  Juudging from the dialog I think it's safe to say it's always a pleasure for us to be working with you.

When I asked if I should "fill" unused space, I should have asked if I should fill with "FFFF". 

SPRAAQ2 states that this is so that CKFA can process continuous blocks of data (something that I too would like to do, anyway, I think; I dont' want to have to skip flash memory addresses while programming flash with application code binary data incoming continuously, upon request of each 128 word message, via the message stream), to provide an illegal instruction trap at those unused addresses, and to leave those unused addresses alone - unwritten/erased - while programming the flash.

When you say that the application needs to be able to run with no resources except for the Control Law Accelerator, this means no FPU, no boot.asm, etc., from the RTS library ?

And yes, Trey, it's the F28335.  So, because I can't run without any "resources", I will not be able to perform a code update (write a buffer of data sitting in RAM to flash) with 0 downtime (do the writing to flash in background, non interrupt service routine, execution - my entire program runs in an interrupt), where the buffer sitting in RAM is periodically filled with incoming application code which my own SCI routine receives within the interrupt, at a byte per interrupt service ?  If I wanted to write 4K of data sitting in RAM to flash, why can I not do that ?

What is meant by "FlashAPI will need to be accessed by my application at some point" ?  Are you referring to the same application that I run with 0 downtime now, while not programming flash ?  That I can do something with my real application doing the downloading and reprogramming short of having 0 downtime ?  Or are you referring to a different application, whose sole purpose is to boot-up loading the CKFA or Flash API either to RAM (a Secure Zone if using code security) or to Flash after which it is copied to RAM via a "copy sections" asm, and to continue by downloading the real application via the CKFA and having that data written to Flash via calls to the Flash API ?

Finally, should I discard SPRAAQ2 and the Flash API document, and design this with  no regard for conversion of incoming big-endian data sitting in a RAM buffer to little-endian for writing to flash, and no regard for the other special CKFA and Flash API functionality, and instead just send a byte stream into my existing real application via existing SCI interface to populate a RAM buffer and periodically memcopy the buffer into successive, adjoining blocks of Flash ?  Like my colleagues do with their OMAPS ?

The F28335 FlashAPI document, on page 7, provides a list of API Do's and API Don'ts.

Among the Don'ts is " Don't execute an ISR from flash/OTP" that if the interrupt can occur during flash erase,program, or depletion recovery.

Can I execute an ISR residing in RAM even if the interrupt occurred during flash erase,program, or depletion recovery ?

Filling with 0xFFFF certainly won't hurt anything, so if it works for your application go for it.

What I mean by only use the CLA is that if you want to program flash without ANY interruption to your application the application needs to be able to run completely on the CLA.  Some of our server power supply guys are requesting this because they want zero downtime during a firmware upgrade.  Given that you are on the F28335 which doesn't have a CLA, I'm afraid that at some point during the upgrade the main application will have to stop.  This is required because the FlashAPI code will run on the main CPU and will also disable interrupts.

You are correct, you can NOT perform a flash operation with 0 downtime.  You can certainly program 4k of data sitting in RAM to flash, but the main application will have to stop for a bit to do so.

I mean that the application that you want to run with 0 downtime will make calls to the FlashAPI which will need to be located in RAM.

How you design this is up to you, but given what you want to do (0 downtime firmware update) I don't think this guide is suited to what you want to do.  I would take care of any data massaging on the host to ensure that the embedded application has to do the least amount of work possible.

To answer your second post:

The guide is correct, AND....

You can execute an ISR from RAM during these flash operations, BUT several of the API calls disable interrupts so you may find your application behavior intermittent during these calls.

Trey

I get it, and in retrospect it should have been clear from the guide, that filling with ones is not a must.

"You are correct, you can NOT perform a flash operation with 0 downtime.  You can certainly program 4k of data sitting in RAM to flash, but the main application will have to stop for a bit to do so."

"I mean that the application that you want to run with 0 downtime will make calls to the FlashAPI which will need to be located in RAM."

Are you aware that my entire application, executes from RAM ? 

In fact, after initialization, everything executes from within a 40KHz interrupt, everything that is not included in Main's background loop, which is nothing at this time.  But I had planned to take my incoming message buffer and copy it to flash while executing in the background. Why would te main application have to be stopped for a bit to program a 4K buffer sitting in RAM to flash ?  Because even the programming of a block that size takes longer then the time between 40KHz interrupts (25usec, 3750 CPU ticks), which would be the maximum time available to the background, if I did nothing in my ISR ?

Is there a minimum size that has to be programmed, or only a minimum size (a sector) that has to be erased ?

The data coming from the host will apparently have to be a BIN file produced by the COFF to Hex converters as specified in the Guide and the FlashAPI documents. The expectation is that the incoming data would be deposited in a buffer that would be transferred as is to flash.  I get what you are saying, I think: that any endianness issues should be pre-compensated for on the host side.  Does the converter's outputs have to be pre-conditioned ?  I did not pull that endianness question out of thin air but saw it mentioned in one of the documents or in a code snippet or something.

And since my last post I had finally read some of the FlashAPI document for the F28335 where there is an indication that interrupts are disabled during flash operations.  I was not sure how absolute this statement is.  But now, after re-reading it I am getting more certain that it is absolute.  The uncertainty arises from the statement in Step 9 (which corresponds with Section 14), an Optional step for my application to perform before calling any API Function, that the application can optionally disable global interrupts before calling an API function.  Then the description of what the API function will do includes the statement that the API function performs the called operation and then disables and restores global interrupts around the critical code segments.  So, it performs the called operation and then disables and restores interrupts.  Makes no sense to disable/enable after performing the called API function.  So I guess what is meant (is it ?) is that the API function is called; the API function executes some stuff before getting to a critical section; the API function disabled interrupts, the API function executes critical stuff, the API function enables interrupts, the API function executes some more uncritical stuff after interrupts are disabled, the API function terminates.  And none of that is executed by the user, much less optionally.  And yet, even though the API function(s) (which ones ?) will disable interrupts itself, the application may do it in advance anyway.  Why ?  Just a long term disable for the entire erase/program/verify duration, for those who are not looking to minimize down time ?

Are the API Library components' source code available ?

Hello everyone,

I am in the exact same case that Greg describes. My main application resides in flash memory and I have couple time-critical functions residing in SARAM. A host computer communicates with the DSP via SCIA and I want to implement an on-field firmware upgrade via SCIA. My SCIA functions are located in SARAM, interrupt based and use FIFO.

I have read the Flash API documentation from controlSUITE and I want to make sure that I have understand everything here is the sequence I should follow :

1. The Host computer triggers the firmware upgrading via a SCIA call
2. The DSP copies the Flash API to SARAM.
3. The Host transfers the new firmware to DSP via SCIA. SCIA related code shall be executed from SARAM right ? Would it be the role of the callback function as presented in the example program ?
4. The DSP buffers the received data in SARAM and copy it to Flash when buffer is full.
5. Once copy is done, execute checksum routine on copied code and reboot the DSP.

I have couple questions:

Is this approach correct ?

Can I use safely my SCIA functions since they are interrupt based (FIFO) ? 

Any comments are welcome. Thanks for your help.

Cedric,

For the most part this approach is correct and will work.

1. Correct
2. Correct
3. SCIA code doesn't need to be in RAM, only the FlashAPI code and the data which is to be programmed into flash.  The callback function can be used to execute user code during the flash process.  A good example of this would be kicking the dog.
4. Correct
5. Correct

Thanks for your help, Trey, that answers my doubts.