Interrupts during flash write

Both the F021 Flash API reference guide and the F035 Flash API reference guide state that API routines must be run in privileged mode to allow access to the flash control registers. F035 also makes reference to accessing the "interrupt disable bits" whereas F021 doesn't. Given that it is not possible to disable FIQ interrupts once they are enabled (unless you start modifying VIM registers), this is a bit of a confusing statement.

Can somebody from TI please confirm whether interrupts are disabled within the functions or need to be disabled prior to calling any of the F021 Flash API functions?

If interrupts are disabled, could you also please state how this relates to FIQ interrupts?

Thanks,

Richard

In theory, the F021 API should operate correctly with interrupts enabled.  It is a test case that I have not had time to look into, but it is something on my list of things to do.  Additionally, the F021 Flash should support generating interrupts when the Flash State Machine finishes an operation.  Here again, I have not had a chance to test this yet, but when I do I will be generating an application note on this usage.

Hi John,

Thanks for responding. Do you have a timescale for doing this work? It's fairly vital for us to know whether we can use Flash memory (both main Flash and EEPROM emulation Flash) with interrupts enabled.

Regards,

Richard

Richard,

I currently do not have a time frame for completing this, but I will check with a couple of other groups to see if they have already tested this.

Hi John,

I'm a colleague of Richard's. We are still interested in knowing the results of this test and also any App note that may have resulted. We have tried not disabling interrupts and this seems to cause problems with the Flash library. Maybe a move to F021 V2 would help? We can try the beta version.

Cheers, Tony

Hi Tony,

I have not had a chance to write up an App note on this.  I did check with our verification team and they tested Flash operations while interrupts were enabled.  The latest beta version of the F021 Flash API v2.0 is available with the latest version of HALCoGen.

Hi John,

Thanks for your prompt response. I've just tried F021 V2 and have the same problem. The symptom simply without a lot of investigation, is that the processor just locks up. I will investigate this further, but something that occurs to us is that this might be a problem with routines running from within the flash bank that we are erasing. We have moved the flash routines themselves to RAM and would normally have disabled interrupts around them. The rest of our code is in flash and is in the same bank that we are erasing (we are using the 1227 which only has banks 0 and 7), Could our problem be because the interrupts we are now allowing are running from the same flash bank?

Cheers, Tony.

Hi Tony,

Yes, you will have an issue if your interrupt vectors or the code that the vectors jump to reside in the same bank as the Flash operation is occurring.  The CPU will stall until the Flash operation is complete.  One theory we have here is doing a RAM memory overlay over the Flash based interrupts to avoid this issue.  Unfortunately, we have not yet tested out that theory.

Hi John.

Okay, thanks for that. We'll either have to modify our code to run in RAM for those routines affected (which is probably okay for our bootloader but not our main app), or move to a device with more than one bank, such as the 2124.

Cheers, Tony.

Sorry John,

I've just thought of a couple of questions. When the Flash API is running:

1. Presumably the HET will continue operation, so a HET triggered SPI transmission will still occur accurately for example?
2. Likewise, DMA transfers would presumably continue as normal?
3. Would the HWCRC module continue without stalling?

Hi Tony,

I have forwarded your questions to some colleagues here as they are outside of my knowledge domain.

Tony,

Strictly speaking those IPs will keep running if the CPU is executing the flash API.

However, all of the IPs could be setup to need periodic CPU intervention say to service interrupts.  Or they could be pretty autonomous.

So the practical answer will depend on how the HWCRC and DMA are configured and what sort of code is running in the N2HET.

Best Regards,

Anthony

Hi John,

Sorry, another question. I have moved my interrupt service routines and all functions they call to RAM. When I allow interrupts during flash operations I get an ABORT (PREFETCH) exception. Is this most likely to be because I haven't tracked down all functions required by the ISR and moved them to RAM or is there another explanation?

Also, are all flash read/write/execute operations within the same bank prevented when running the FAPI, or is it just flash execute?

Cheers, Tony.

Hi Tony,

The only operations that causes the Flash Memory Controller (FMC) on the active bank on the device to stall/abort, etc. are an ongoing Program, Erase Bank or Erase Sector operations.  The only commands the FMC allows for all banks while either the Program or Erase Sector (but not Erase Bank) is the suspend Program and suspend Erase commands.

Which leads me to this thought, instead of moving your ISR routines to RAM, you could issue a suspend command as long as your not erasing the sector where the ISR routine lives (and not reprogrammed the routine yet).

Using the v2.0.0 API, this would be something like:

FAPI_SUSPEND_FSM;

While( !(FAPI_GET_FSM_STATUS & 0x6);  /* Wait for the operation to suspend */

/* Call ISR routine */

if (FAPI_GET_FSM_STATUS & 0x2) { Fapi_issueAsyncCommand(Fapi_ProgramResume);}

else { Fapi_issueAsyncCommand(Fapi_EraseResume);}

Of the example above is barebones for illustrative purposes and not fully fleshed code.  Also suspend is a single command, but you need to either issue a program resume command or erase resume command based on which activity is suspended.

Let me know if I am confusing more with this answer.

Hi John,

Thanks for the info. As you suspected, I'm not entirely clear on this. I'm not sure where the suspend should be issued. This would presumably not be in the ISR itself as that would be too late.

As I understand it (and as witnessed on my Lauterbach Trace32), on FIQ a jump is made to flash address 0x1C, the instruction at this point loads the PC with the ISR stored in 0xFFFFFE74. We are now in the ISR!

The problem I am seeing on the Lauterbach is that most FIQs are executed correctly (and essentially I only have one FIQ running, no IRQs), but then I get an FIQ which jumps to 0x1C, this access to 0x1C then immediately cause my DATA (PREFETCH) exception (so PC becomes 0x0C).

I will try your suspend idea but need you to explain to me a little more where to put it.

I would like to pursue the problem outlined above where jump to 0x1C immediately cause a DATA (PREFETCH) exception. Do you have any ideas on this. Is it because 0x1C is actually an execution from flash and not RAM, and this causes a problem for the FAPI?

Cheers, Tony

Hi Tony,

The problem is with the FMC and not the API with 0x1C being in Flash (not being picky here, just trying to maintain a distinction between the API and the FMC).  Why it is jumping to 0x1C, I will need to forward that on to my colleagues to see if they know why.

I honestly have not written ISRs for these devices, but I would expect something like:

RAM

    FIQ Vector -> points to ISR routine in RAM

    ISR Routine in RAM  ->  Suspends Program or Erase Sector operation

                                                Calls ISR Rountine in Flash

                                                Resumes Program or Erase Sector operation

Flash

    ISR Routine in Flash

Tony,

A way to debug your problem is to set a breakpoint on the FIQ vector at address 0x1c.
Once a FIQ is generated, the CPU will jump to 0x1c and will stop there.

The instruction at 0x1c is an indirect load pc with the content of address 0xFFFFFE74 (FIQVECREG)
This register is located in the VIM module and should have the address of your ISR routine for FIQ. The FIQVECREG is loaded from the VIM RAM by the VIM module itself.
The VIM module knows that the current interrupt is a FIQ and based on the request number, it will read from the VIM RAM the address for your ISR.

In your case, is this prefetch error is happening all the time?

Can you try this debug method and let us know the result?

Hi John, Jean-Marc,

John, I understand your point about the Flash Memory Controller (FMC) responsibility and why you make it.

Jean-Marc, My FIQ is running at 16 Khz with no problem. As soon as the flash erase operation is started, the next FIQ causes jump to 0x1C as expected, but the execution of the indirect load PC then causes the DATA (PREFETCH) exception. so my PC goes from 0x0800xxxx (some RAM address where my flash routines are running), to 0x1C to 0x0C. This happens every time. It is the FIQ occurence causing the DATA (PREFETCH) exception. If I disable interrupts whilst flash operations are in progress then there is no problem.

I'm thinking that there is some interaction here that is not expected. We are advised that the F021 1.51 works with interrupts enabled. I have yet to try with F021 2.0 but will give it a go later today.

Regards to both, Tony

Hi Gentlemen,

I haven't yet tried F021 2.0, but I'm still thinking that my problem is caused by the FIQ causing a flash execution from the same bank that is being erased, which is not allowed. Have you any thoughts on the matter.

I wonder if I am able to transfer vector handling to SRAM as hinted at in post http://e2e.ti.com/support/microcontrollers/hercules/f/312/t/164233.aspx. I'm not sure how to proceed with trying this. Would I essentially have to map all my flash code into SRAM or just the vectors. How would the SRAM be set up if a CPU reset is required, is it essentially retained through the CPU (warm?) reset? Are you able to elaborate on this?

Regards, Tony

Hi John,

I'm really not keen to go down the route of transferring vector handling to SRAM.

We do seem to have a potential work-around to the problem of FIQ/IRQ interrupts accessing flash for register vectored interrupts at 0x18 and 0x1C. If we modify our architecture to change all FIQs to IRQs instead, and then use the hardware vectored interrupt function to dispatch IRQs automatically to the ISR in RAM then interrupts will be supported during flash operations on that same bank. I have tried this and it does work (no DATA (PREFETCH) exception).

This workaround is a bit of a pain, and we can only get away with it as the problem exists in our bootloader only, which has much reduced functionality compared to our application.

What would be ideal is that FIQs could also be supported by the hardware vectored interrupt technique, which only supports IRQs. I wonder why this restriction exists; it does seem a little odd. Do you think it possible that in future, the FMC might supported FIQs with hardware vectored interrupts?

I guess that using F021 2.0 instead of F021 1.51 would not impact this as it is an issue with the FMC.

Regards, Tony

Hi Tony,

From what I understand about this in discussions with a colleague, the FIQ interrupt issue is at the device architecture level and therefore a modification to the FMC on future devices would not solve what you are seeing.

I will pass along your issues to the architecture team to have them keep it in mind on future devices.

Hi Tony,

The FIQ limitation is introduced by the ARM v7R architecture as implemented by ARM in Cortex R4.  FIQ is not part of hardware vectoring so that it can be directly accessed for use as an NMI with fastest possible response.  Typically, this is an advantage, but in this case it causes an issue.  As you noted, there are two alternatives already supported in the device architecture - swapping the SRAM and flash so that the SRAM is mapped at 0x0 to manage the vector table or use IRQs with vectoring instead of FIQ.

Best Regards,
Karl