Equip yourself to optimize PSoc4 MCUs for Evs at the EV Webinar. Click here to register.

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

PSoC™ 4 Forum Discussions

Level 2
Level 2
10 sign-ins 5 questions asked First solution authored

I am using a CYBLE-022001 and need to verify the integrity of FLASH at startup, preferably by using a CRC calculation. I noticed in the Intel Hex File, there is a location at the end of the file that stores some sort of checksum as shown below.


This same checksum is used and verified by PSOC programmer when the "Verify" button is clicked after programming the part. In the example above, E05C is the checksum that is verified. So my questions are:

1) Is this checksum stored in some non-volatile memory (0x90300000) location on chip and

2) If it is, where can I find the calculation that creates and/or verifies this checksum

Thank you in advance!!!

4 Replies
Level 7
Level 7
500 replies posted 250 replies posted 250 sign-ins


2 documents of interest:
CY8C4xxx, CYBLxxxx Programming specification (  See Section 2.3.  This has the format of the .hex file and Metadata section and includes the FLASH checksum (summation or CRC method).  Yes, in the .hex file the checksum is stored at 0x90300000.  I believe it's also stored in PSoC FLASH at the same location, but I'm not 100% sure (since internal user FLASH doesn't go up to that address).
PSoC® 3, PSoC 4, and PSoC 5LP UART Bootloader (  This doc (AN68272) includes lots of FLASH programming details which will assist in understanding how the .hex file is parsed.  See Appendix A for memory and metadata details.

Something to understand: the addresses for (12 bytes) Metadata in the .hex file are NOT the addresses used to store this information in the PSoC.
"The address space of the hex file does not map to the physical addresses of the CPU (other than the user’s flash, which is a coincidence). The programmer uses hex file addresses to read sections from the hex file into its local buffer. The programmer writes this data into the corresponding silicon addresses."
The metadata section is the highest 64-byte block of flash on the device.

I've not looked for the equation Cypress uses for CRC calculation.  The usual checksum is just a summation of the bytes for application code.  This is detailed in the doc's I've pointed to.  The CRC calculation equation will likely be in one of the .hex file parsers.  Have a look thru this doc and associated .zip folder:
PSoC 4 Programming Using an External Microcontroller (HSSP) (  AN84858
Infineon Technologies download the file, it has all the parsers.


Thank you for the reply. VERY,  VERY HELPFUL!! I didn't notice any CRC calculation in the hex file parsers, so I've got no issue in writing a CRC generator myself and manipulating and adding the CRC in the Intel Hex file post build including the checksum at 0x90300000, which as you point out is a simple byte addition checksum.

I ran some simple build tests to see if anything else changed in the Intel hex file, and yes, the last 2 bytes considered "Internal Use" at address 0x90500000 do change also. After some testing, it looks like, again, these bytes are a simple byte addition of user FLASH bytes and something else which I can't make out. If these "Internal Use" bytes are not correct, one can not use PSOC Programmer to program the PSOC, which is a production requirement. Going  to wing it and update these last 2 bytes also hoping that soemthing else doesn't "break". I understand not including a generic CRC calculation option as part of the post build tools, but having to update "Internal Use" metadata and not giving a clear explanation of this metadata, especially at address 0x90500000 is troubling.



I hunted thru app notes and other component datasheets.  I couldn't find a description of the "Internal Use" 4-byte field.  The doc's say it's something only PSoC Programmer uses and 3-rd party programmers can ignore it in the .hex file.

I also looked thru ppcli (PsoC Programmer CLI) commands.  Couldn't find anything related there either.

Speculation: maybe the "internal use" field is a checksum of all programmable FLASH including the FLASH metadata field (normally excluded from this calculation).

BTW, why do you want to change the "internal use" bytes?

I'd suggest you start another thread specifically asking about the "internal use" 4-byte field in the .hex file metadata.  Hopefully someone from Cypress/Infineon will reply.


Thank you again for the quick reply! The only reason that I need to change the internal use bytes is that if those bytes aren't updated with the correct checksum, PSOC programmer declares the Intel Hex file invalid and will not program the device. The project requirement is to use PSOC programmer at the factory.

I'll take your suggestion and post a question about internal bytes in another thread