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

PSoC™ 6 Forum Discussions

Level 1
Level 1
First like received 5 sign-ins First reply posted

I have a project using a CY8C6x4 processor (CY8C6247FDI-D32).  We have a requirement to service an interrupt on the M4 core at a very high rate (~ every 640us).  We also have a requirement to write to flash memory using the M0 core while this interrupt is running.  The M0 and M4 cores are running from flash in sector U1 (0x10040000) and the flash being written is U3 (0x100C0000).  Below are a bunch of questions related to writing to flash using "partial blocking" methods.

Looking at the PSoC Peripheral Driver Library Flash Section (link) you can use partial blocking methods to try to keep the "non-flashing" core running while doing a flash erase and a flash write.  The documentation has Figure 1 which shows some general timing for the StartErase() + StartProgram() method and the StartWrite() method.  I have tried both and it looks like both processors get "locked" for a period of time. 

Figure 1 has a Legend that shows "Available to read from flash", "Busy with SRM code (CM0+)", and "Blocking-out SRAM".  I can figure out what (and see from my traces) what the first two mean.  What I don't understand is what does "Blocking-out in SRAM" mean?  Does this mean the processor can't execute from SRAM?  Also what are the implications of this time period?

I'm trying to get something useful done on the M4 during the "Blocking-out in SRAM" period.  From what I can see from traces I have collected is that there isn't much the M4 can do while the M0 is "starting the erase" and "starting the program".  The code that I'm running is not getting interrupts during this period.  So are both processors blocking in an NMI interrupt?  Are interrupts disabled on both processors? 

I understand that the M0 is tied up working with SROM and IPC during these times.  I also understand that at least on the M0 a critical section cannot be entered.  Is that true for the M4 as well?  It the M4 locked up on IPC during these times as well?

I'm wondering if I can execute SRAM code on the M4 during this "Blocking-out in SRAM", but it isn't clear to me what blocking-out means.  Also I'm not sure why I can't use Flash during this time since the sectors I'm using should be isolated.  I have dug into the CY code that is interfacing with the SROM/IPC and it is running in SRAM (so that it is not using the flash or the flash cache).

Any help on this would be greatly appreciated and I suspect others would like to have a better understanding of what is going on while the SROM code is executing.

Best Regards,

4 Replies
10 likes given 50 solutions authored 100 replies posted

Hi @lhoag972 ,

Both CPUs –Cortex® M4 and Cortex® M0+ – are 32-bit. CM4 runs at up to 150 MHz and has a
floating-point unit (FPU). CM0+ runs at up to 100 MHz. CM4 is the main CPU. It is designed for a short interrupt response time, high code density, and high throughput. The CM0+ CPU is secondary; it is used in PSoC™
6 MCU to implement system calls and device-level security, safety, and protection features. CM0+ is also recommended for functions such as BLE communications and CAPSENSE™


Please refer to https://www.infineon.com/dgdl/Infineon-AN215656_PSoC_6_MCU_Dual-CPU_System_Design-ApplicationNotes-v... for more information.


Please allow us to get back to you for the remaining queries.

Kind Regards

Arpit Srivastav


Hi Arpit,

Thanks for your response.  Here are hopefully some more specific questions.

1) In the PSoC 6 Peripheral Driver Library, Flash Section (link) for Figure 1 I cannot find any explanation for what "Blocking-out in SRAM" means (see the Legend for Figure 1).  I need details on what a CPU Core in "Blocking-out in SRAM" can and cannot do.  I.e:
a) Are the address and data buses locked?  Not sure what blocking out means.
b) Is the chip held in some interrupt state?  I.e. is the processor running in an NMI interrupt routine and nothing else can happen until that code releases?
c) Can the core run code as long as it doesn't try to enter a critical section?
d) What interrupt level is the core held in during this time?

I can probably find these things out experimentally, but I was hoping that were was some more detailed documentation on what is going on in the core that is not performing the flash/SROM operations.

Again, the core (M0) that is performing the flash SROM functions is running from UFLASH S1 (0x10040000) and is trying to write to UFLASH S3 (0x100C0000).  The other core (M4) is also running from UFLASH S1).

And I have read the caveats in the section "Constraints for Partially Blocking Flash operations".  This section does not give much in the way of details for what a non-flash operation core can and cannot do.

Best Regards,


50 sign-ins 50 replies posted 25 replies posted

Lenny, you state:

"I'm trying to get something useful done on the M4 during the "Blocking-out in SRAM" period.  From what I can see from traces I have collected is that there isn't much the M4 can do while the M0 is "starting the erase" and "starting the program".  The code that I'm running is not getting interrupts during this period. "

The PDL documentation states:
Application code execution from flash is blocked for only part of flash write duration for both cores.

So it is an expected condition that the cores running from Flash will have a period of time when they will be blocked. I know you want to understand the "why" around this phenomenon, but I'm sure that has a lot to do with critical setup that needs to be done to erase or write the flash (and hence why it is done with SROM routines built into the part).

Let me see if there is anything more detailed I can find and I will get it to you privately.


Hi Corey,

Thanks for the information.  I'm still looking for some detail on what the blocking mechanism is for the core that is not doing the flash operations.

Our workaround was to move ALL of the M4 code to execute out of SRAM instead of running from FLASH and to #define CY_FLASH_RWW_DRV_SUPPORT_DISABLED  to disable RWW functionality on both cores.

From an experimental point of view this seems to allow the M4 to continue running while the M0 is writing to FLASH.  I would like to be sure that I just this is a 100% solution.  The M4 code needs to run without interruption while the M0 is writing to FLASH.  So I'm trying to understand what this blocking mechanism is; i.e. NMI, bus locking, queue locking, etc.

Best Regards,