Erasing a part of code without re-flashing

[Ramesh_R]

Hi,

May be this be a fancy query, but still a thought as an engineer,

I have a code section in my project which is executed only once when I run the project for the very first time but after that for the entire duration of running that project this section won't be used. Can I know whether we have a method to disable this portion of the code from the flash permanently without reflashing the code? Whether there exist a method to store this portion of the code temporarily in some location other than Flash and execute it from there only the very first time, so that the flash space can be used entirely for implementing the continuously executing code section?

I am using PSoC5LP as the core of my project.

[Len_CONSULTRON]

Ramesh,

There is a way to declare a location in FLASH to be emulated EEPROM.  In theory, you could store code there and execute from it.  Once executed, this section can be used for EEPROM storage of non-volatile parameters as the Em_EEPROM was intended.

Another thought:  Theoretically code can be executed from RAM.  The problem is getting the executable in RAM.  I believe there is a communication mechanism to load RAM through the SWD interface.  I haven't used it.  This would allow you to load RAM with your executable at original FW Flashing time and once completed the RAM can return to normal RAM usage.

[BiBi_1928986 · Accepted solution]

That's a great idea Len!

I've used SWD to program serial numbers into 5LP RAM using ppcli scripts.  The serial number is later stored in emFLASH.  (Dont' ask me why, but that's the way the customer wanted it done).

Using ppcli, I first program the FLASH, store serial number in RAM, then execute.  The "write" command is very simple:
DAP_WriteIO(IN address, IN data)
And for reading back:
DAP_ReadIO(IN address, OUT data)
The above is done 1 byte at a time.  You can't send a string of bytes all at once.  And, you have to increment the address.

So, RAM could be loaded with code in 5LP in the first 32kB RAM bank (the second 32kB RAM bank doesn't allow execution of code).  I would also store a non-zero checksum somewhere as well.  After execution of the run-once code, the FLASH code could wipe out the RAM image.  The next time 5LP is reset, it has to check if the RAM checksum is valid.  If not, it hops over it.

In a similar fashion of using a valid checksum, or a flag, with run-once code stored in FLASH, a flag could be stored in EEPROM or emEEPROM to indicate if the run-once code should run or not run.

[Len_CONSULTRON]

BiBi,

Thanks for the well documented reply.

I didn't know that only the first 32K RAM bank can run executable code.

[BiBi_1928986]

Hi Len.

I discovered the 5LP upper/lower SRAM banks when I was testing some code in PSoC 4 SRAM.  I had tried to move same code into a 5LP device.  It would not work at the same address (above 0x20000000 where PSoC 4 SRAM starts).  Upon reading AN89610, I discovered the 5LP has 2 banks of SRAM and only the lower bank supports code execution.  The reason: each bank resides on a different internal bus.  This is explained quite well on section 2.2.2 with a nice diagram.
PSoC® Arm® Cortex® Code Optimization (infineon.com)
Since PSoC 4 only has 1 internal bus, the code worked above address 0x20000000.

And, FYI... there's a good description of 5LP DMA in section 11 and how/why SRAM gets re-mapped out of executable code space.  I mention this because we don't know if Ramesh_R is using DMA and if so, this could thwart attempts to execute code out of SRAM.