const uint8 rpp_uio_16_eeprom[RPP_UIO16_EEPROM_LENGTH] = {
    0x52, 0x2D, 0x50, 0x69, 0x01, 0x00, 0x02, 0x00, 0x6D, 0x00, 0x00, 0x00,
    0x01, 0x00, 0x00, 0x00, 0x31, 0x00, 0x00, 0x00, 0xC0, 0xE9, 0x73, 0x39,

The EEPROM example I included in a previous log was a CAT24C04. This is a smaller EEPROM and only has one single word address at the start of the I2C command (after the Slave Address). I'm not sure how 8-bits work with the CAT24C04 since it has 512-bytes which should need 9-bits of address. 

Regardless of this, the 24C32 EEPROM used on the hat requires two bytes for address. I set the image to another part and was able to get it to successfully write to the ID EEPROM.

To do this I added conditional code which uses enums for the different card types. This lets the card type be selected by the main( ) calling code.

enum EEPROM_Images {
    RPPUIO16,
    RPPGVSCFG,
    RPPSOC
};

The call, then, looks like:

writeEEPROM(RPPGVSCFG);

The dump of the EEPROM on PuTTY looks like:

Read from the EEPROM
0000  52 2d 50 69 01 00 02 00 75 00 00 00 01 00 00 00  R-Pi....u.......
0010  39 00 00 00 7b 27 6f 99 72 25 6c bd 33 46 3e 35  9...{'o.r%l.3F>5
0020  9f c8 a7 3e 04 00 01 00 0f 12 6c 61 6e 64 2d 62  ...>......land-b
0030  6f 61 72 64 73 2e 63 6f 6d 52 41 53 50 49 2d 50  oards.comRASPI-P
0040  4c 55 53 2d 47 56 53 2d 43 46 47 7a 43 02 00 01  LUS-GVS-CFGzC...
0050  00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0060  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0070  00 00 00 ed 6e 00 00 00 00 00 00 00 00 00 00 00  ....n...........

The different card type can be seen in the text to the right. Setting the calling value to the PRR-UIO-16 card and doing a write followed by the read shows:

Read from the EEPROM
0000  52 2d 50 69 01 00 02 00 6d 00 00 00 01 00 00 00  R-Pi....m.......
0010  31 00 00 00 c0 e9 73 39 59 5c 8b af 62 4f 19 32  1.....s9Y\..bO.2
0020  fe 3f 2d d5 05 00 01 00 0f 0a 6c 61 6e 64 2d 62  .?-.......land-b
0030  6f 61 72 64 73 2e 63 6f 6d 52 50 50 2d 55 49 4f  oards.comRPP-UIO
0040  2d 31 36 f2 9f 02 00 01 00 20 00 00 00 00 00 00  -16.............
0050  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0060  00 00 00 00 00 00 00 00 00 00 00 ed 6e 00 00 00  ............n...
0070  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

So it looks like it's working well now and it is callable with the different board EEPROM contents.

Process to Make a New ID EEPROM for the Raspberry Pi

I've put up bits of this already but here's a thumbnail sketch of making an ID EEPROM for Raspberry Pi Hat. These steps only need to be done once for a particular Hat design or if the device tree needs to be updated for the Hat.

• Download the tools from the GitHub RPi Hat repository to the Raspberry Pi. There are additional helps there.
• Study the Design Guide (from above). Particularly, read the ID EEPROM section.
• The EEPROM format section is here. Don't get scared. There's a tool to help make the file in the proper format.
• Edit the eeprom_settings.txt text file for your particular hat design
• eepmake: Parses EEPROM text file and creates binary .eep file. Run this program on the Pi. It will create the eepcfg.eep file.  eepmake could probably compiled to run on any computer and probably doesn't have to be run on a Raspberry Pi but who doesn't like to play with their Pi?
• Run eepmake with:

  ./eepmake eeprom_settings.txt eepcfg.eep

• eepcfg.eep is a binary file. Use a tool like HxD to open the file. Export the file as a C array. Use a file name which distinguishes the file from other hats.
• Add the hat file to EEPROM_Images.c file in the PSoC code.
• Change the type to const uint8. The result should look like:

  const uint8 rpp_uio_16_eeprom[RPP_UIO16_EEPROM_LENGTH] = {
      0x52, 0x2D, 0x50, 0x69, 0x01, 0x00, 0x02, 0x00, 0x6D, 0x00, 0x00, 0x00,
      0x01, 0x00, 0x00, 0x00, 0x31, 0x00, 0x00, 0x00, 0xC0, 0xE9, 0x73, 0x39,
  

• The length of the file was indicated in comments in the C array file created from HxD.  This could also be created by srec_cat (part of srecord).
• In the EEPROM_Images.h file.
• Make a #define for the length of the record (example below).
• Make a function prototype for the array. It should look like:

  #define RPP_UIO16_EEPROM_LENGTH 109
  extern const uint8 rpp_uio_16_eeprom[RPP_UIO16_EEPROM_LENGTH];
  

• This lets the write function access the EEPROM data.
• This process replaces all of the I2C configuration on the Raspberry PI.
• No need to do I2C port scans.
• No need to do eepflash.
• No need to do eepdump.

With the ID EEPROM programmed the card can now be identified by reading the ID EEPROM. This should prove useful for card testing, particularly repeating tests since the PSoC software can detect the card type automatically. If the part is not programmed, it can ask the user to select the EEPROM image to program into the part. The correct card tests can then be automatically selected and run.

EEPROMs come with 0xFF from the factory so it should be easy to detect if a part has ever been programmed. These values are set in the ExtEEPROM.h file and are found in these values:

#define MAX_ID_IMAGE_SIZE   128
#define NUM_32_BYTE_BLOCKS  4
#define EEPROM_BLOCK_SIZE   32

These could change with a different EEPROM. Consult the part data sheet for other parts.

To have a table larger than 128 bytes. the defines above would need to changed. The three values are inter-related. The first (IMAGE_SIZE) has to be larger than the ID file. The third value is dependent on the EEPROM part but the CAT24C32 has 32-byte blocks. The second value is the first divided by the third value and indicates how many blocks must be written.

The code zero pads past the end of the ID EEPROM data.