TC27x interrupt state while operating with Flash

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
User20005
Level 2
Level 2
5 sign-ins 5 questions asked Welcome!
Hi,

We are usingTC275 CPU and are working on a system that will use internal PFLASH and DFLASH . We are interested in writing, erasing and reading from it and have few questions regarding these operations.

1. When sending commands such as IfxFlash_enterPageMode(), IfxFlash_eraseMultipleSectors(), IfxFlash_loadPage() or IfxFlash_writePage() is it __neccessary__ or __desirable__ to have interrupts disabled?
2. What happens if some interrupt is triggered and serviced while writing to Flash command register?
3. Can the command sequence be interrupted under any case or must it be completely uninterrupted? Same for PFLASH and DFLASH?
4. After command is issued to Flash can interrupts be immediately re-enabled? Meaning even before erase or write has completely finished.
5. Is there any, and if what, difference regarding interrupt state between PFLASH and DFLASH?
6. Any other thing we should know about when working with Flash?

Case A:
RTOS running on core0 with one task and one hardware generated PWM (real case many tasks and many interrupts are used).
Requirement is that PWM must under no circumstance stop and must always be running.
Task at some point starts writing or erasing some DFLASH memory region. Global interrupts get disabled. PWM stops!!! Bad!
The solution? Of course if Flash command cycles for DFLASH can be interrupted then there was no problem to begin with. But if you suggest otherwise, then is there any practical solution?


Thanks and best regards
0 Likes
12 Replies
Darren_Galpin
Employee
Employee
First solution authored First like received
1) Interrupts are handled by separate parts of the device and run independently from each other. You do not need to disable interrupts to program the flash.
2) Depends on whether your interrupt handler does something to the flash controller (DMU). The DMU will simply wait for the next command in the sequence, so what it does depends on what you next write to it.
3) A command sequence can be interrupted. You can write a clear command or reset to read at any point during a command sequence to take it back to idle, and any incorrect input in the sequence simply causes a sequence error, which can be cleared.
4) This has no bearing on the flash programming. You choose what you want the interrupt behaviour to be. You can enable interrupts from the DMU, and this allows the CPU to monitor for certain errant behaviour without needing to poll registers.
5) When programming via the DMU, there isn't any real difference between DFlash and PFlash. The main difference is between DFlash0 and DFlash1 when HSM exclusivity is enabled.
6) If the operation is running, you can run a suspend command sequence to halt it at a safe point. This then allows other operations to be done to Flash.
0 Likes
User20005
Level 2
Level 2
5 sign-ins 5 questions asked Welcome!
Thank you for anwsers!

We've tested it by setting up a timer generated interrupt occuring every 100us to 1us.
With DFLASH there was no problem and one could write and erase as many sectors without any issues even with interrupt running at 1us.
When tested erasing PFLASH regions (note that code for erasing is running from PSPRAM !!) ContextManagment TRAP occured. Why and how to solve?

Best regards

EDIT:
We are using IfxCpu_disableInterrupts() and IfxCpu_enableInterrupts() before starting erasing/writing and efter its done
0 Likes
Darren_Galpin
Employee
Employee
First solution authored First like received
If you have a context management trap, that would seem to indicate that there was an issue with the interrupt routine - you can get such a trap if, for example, the located context store size is exceeded. So things to check would be where is your context save being stored to? A PFlash routine should have nothing to do with this, as the PMU will run independently once set off. Even if you have configured it to generate an interrupt, this would happen on an end of busy for example. Are you managing perhaps to get two interrupts close together, so that you are doing more than one context switch? Note that the program/erase times for DFlash and PFlash are different.
0 Likes
Darren_Galpin
Employee
Employee
First solution authored First like received
PS What was the class and TIN of the trap?
0 Likes
Darren_Galpin
Employee
Employee
First solution authored First like received
The function you are calling to disable interrupts sets the CPU ICU interrupt enable/disable bit - this doesn't stop the rest of the system from generating interrupts,
0 Likes
User20005
Level 2
Level 2
5 sign-ins 5 questions asked Welcome!
4829.attach

I've attached the image of what happens when I press pause in debugger. Debugger does not stop by itself even if i wait for 30 seconds and I have to press pause.

4830.attach

Second image is code used to erase sectors where address = 0xA0020000 and n_sectors = 1. After this I do the checks for flags FSR.ERASE, FSR.SQER, FSR.PROER.
0 Likes
User20005
Level 2
Level 2
5 sign-ins 5 questions asked Welcome!
When puased D15 (TIN) has value of 0x4.
0 Likes
User20005
Level 2
Level 2
5 sign-ins 5 questions asked Welcome!
I can create a sample project for you if interested?

EDIT:
Basicaly GPT12 timer running with 100us period and triggering an interrupt that toggles an LED.
And then running code I pasted in previous post for flash erase.

EDIT2:
I should mention that I've checked that my source code for firmware does not go over 0xA0020000.
0 Likes
User20005
Level 2
Level 2
5 sign-ins 5 questions asked Welcome!
Hm.... If I change address the erase to 0xA0220000 then erase completes ok. This address is in PFLASH1 while previous 0xA0020000 is in PFLASH0.
Does this mean that the flash bank containing (PFLASH0) interrupt vector table can not be erased or written while interrupt is occuring.

Does this mean that interrupts need to be disabled if their table is in the same PFLASH bank as being operated on?


EDIT:
Does this mean that the flash bank containing (PFLASH0) interrupt vector table can not be erased or written while interrupt is occuring. -- Even though the address to erase/verify does not point to vector table or any entry in that table.
0 Likes
Darren_Galpin
Employee
Employee
First solution authored First like received
An interrupt itself on CPU0 should not stop the erase.

But we may have found the problem - the vector table is in PFlash0? So when the interrupt happens, the CPU is attempting to read the flash because that is where the vector table is, but access is blocked because the PFlash is busy with the erase - you cannot read a flash bank when it is being programmed or erased. So yes, if the interrupt table is in the flash bank being operated on, then the interrupts should be disabled. Or access the interrupt table via cached addresses, and make sure that the table has been accessed once before the erase so that the table is in the cache.
0 Likes
User20005
Level 2
Level 2
5 sign-ins 5 questions asked Welcome!
Thank you!
0 Likes
JexJiang
Level 3
Level 3
25 replies posted 5 questions asked First solution authored

Hi,I encountered the same problem, how can I solve it?

0 Likes