I don't have direct answer for you. However, since the KIT-049 bootloader is never erased, have a look at PSoC4 bootloader doc's such as AN68272 and AN73854. There might be some useful info in there for you.
Is your intention to have the user defined FLASH:
1) protected against being erased?
2) allow read access through debug or,
3) block read access through debug
I may be going down this same path soon. Hence my interest.
Thanks for the comment.
Good idea looking at the bootloader for the -049 kit, which was before Cypress started embedding the KitProg in a PSoC 5 on the kits.
I've also been directed to some example code loaded onto my PC I wasn't previously aware of @ C:\Program Files (x86)\Cypress\Programmer\Examples\Programming”
Good catch on the clarification. The intention is 1), to protect a section of Flash from being erased.
For Read Protection, I would refer to Device Security in section 14 of the PSoC Architecture Technical Resource Manuals.
PSoC 6 supports separate Application Flash and EEPROM Emulation Flash (WFlash). Hence, you can selectively erase required memory area in PSoC Programmer.
In PSoC 4, Emulated EEPROM is placed in Application Flash and the content will be lost in the 'Erase All Flash' step in Programming Flow. Hence, you can use the bootloading architecture to selectively update bootloadable / user application area of flash without erasing / modifying rest of the flash. You can refer to AN73854 Introduction to Bootloaders and guidelines in Using the Emulated EEPROM Component in a Bootloadable Project - KBA89149.
1 of 1 people found this helpful
I was provided the following elegant solution from the Cypress FAEs Community and given permission to post it here:
Cypress has SFLASH in some of the PSoCs that is not erased thru the programming cycle. It’s not a publicized feature but it’s there and accessible. To utilize the SFLASH, change the pointers used in current flash write APIs to the SFLASH locations defined in Cyflash.h file as described below:
P4M has SFLASH (I think every device has it but only some expose it to the user as we use it for internal trim/calibration/factory settings), our first families that supported it for user area were the BLE devices (used for bonding tables). There is a certain portion the user can access, and it is retained through programming, works well with our bootloader (not included in checksum) so there are some advantages to use it as user space vs. using the code flash.
The original P42/41 devices (non S/M/L) do not expose it to the user and is only used internally.
In creator you can look in CyFlash.h, if CY_SFLASH_XTRA_ROWS is defined, it means the user area is defined, and there will be a number of #defines for the address and size of SFLASH, which you can use with our flash routines to access that area. This area is persistent through programming. Not a well-documented feature, but you can verify in Creator pretty quickly the details. It’s main purpose is for internal trim/factory settings but with later devices we exposed the unused area to end users.
There is one document on it, for the BLE devices, but it should apply similarly to any family that has the SFLASH user space available: https://www.cypress.com/file/206621/download