There is a hex file format document available. I'm not sure where it is on the Cypress site. Try this: https://community.cypress.com/external-link.jspa?url=http%3A%2F%2Fwww.cypress.com%2Fdocumentation%2Fprogramming-specific…
Here are reasons I'm aware of for post-loading unique data into each PCB built.
Serial number (Manufacturing encoding)
Many companies will include a unique Serial number that can identify metrics of when the board was manufactured. If there is a communication standard being used for the product, It is common to create a set of manufacturing specific diagnostic codes to load the Manufacturing metric data into EEPROM. A form of communication standard is the Bootloader. The Bootloader code supplied by Cypress can be modified to add diagnostic extensions for this purpose without resorting to modifying the hex file.
Serial number (Unique system or Global ID)
Many companies will include a unique Serial number to uniquely identify the board in a system (like a PC host) or globally when data is exchanged in a WAN. The Cypress Silicon ID is commonly used in BLE and USB to provide a unique-like number for this purpose. This silicon ID is added to the PSoC chip at Cypress manufacturing.
When using sensors, it is common to calibrate the sensor measurement components to a known reference. To do this, an application needs to be running and communicating to external equipment to force a known stimulus and instruct the end-device to make the sensor processing correction to the expected output result. The correction factor is then stored into EEPROM.
If you are using the first Bootloadable code as this calibration application, once completed and the correction value stored, the second Bootloadable application can be the customer-targeted application with the correction factor that can be read from EEPROM.
Is any of these types of uniqueness what you are trying to achieve?
Thanks for you reply. I did have look for the PSOC 5 hex format on the Cypress website but couldn't find it. I'll have another look. Maybe I'm not searching for the right thing...
What I'm actually trying to do is implement a non-standard bootloading mechanism. It needs to work through our own communication stack that's already highly integrated with an existing product. There are multiple psocs on a custom bus and I need to be able to bootload any of them from our host software.
The way I was intending to do that is have a very simple copier style bootloader, and use our main psoc program (which already handles the coms, checks integrity, can write to flash and importantly works with our driver) to receive and store the new program in a spare region of flash. Then the bootloader would then simply copy it over the main application.
I know how to do all of that, except how to extract the bootlloadable application and the metadata reliably from the compiled hex.
I guess there are probably other ways to accomplish the high level goal... If there's a more obvious way to do it, I'm open to suggestions but I suspect this way will save me a lot of work. I'm tantalisingly close - I basically have all the other elements in place from existing features. Also, this is they way we've implemented bootloading previously on other MCUs so it's got the advantage of familiarity...
The pdf link I provided describes the hex format in some detail. The question: Did it cover enough for you?
I had actually already found a definition of the hex format - my interpretation of the data just didn't seem to match with what I was expecting to see and where.
I have actually worked out what was going on though I think... I've found the meta data - I was just looking in the wrong place!! #rtfd
Those random bits and pieces at the end of the hex are actually way past the end of the flash address space. I still don't know what they mean, but I don't think i need to worry about it...
Thanks for your help
I looks like you're on the right track.
Thanks for your help
I'm not sure I was any help but at least I tried to be.