cancel
Showing results for 
Search instead for 
Did you mean: 

USB Superspeed Peripherals

GrHa_3282776
New Contributor

Hi,

I would like to see an example of encrypting the bitstream of an I2C EEPROM to prevent duplication or reverse engineering.  I understand there is a unique serial number in each FX3 device, just unsure how to access and utilize it for this purpose.  I am using SPI in my application so I can't use an SPI EEPROM.  I would like to use the Windows class driver for a virtual com port, so I don't think I can do a USB boot using a custom driver.  But if that is an option, I would like more info about that too.

Thanks,

Greg

0 Likes
1 Solution
YashwantK_46
Moderator
Moderator

Hello Greg,

You can go ahead and use the registers mentioned in the above thread which mentions:

The unique ID is actually stored in two registers each of 32 Bit.

  

Their address : 0xe0055010 and 0xe0055014.


You can read these registers by declaring two 32-bit registers as follows:

uint32_t reg_data_1;

uint32_t reg_data_2;

and using the following line to read each 32-bit register as follows:

status = CyU3PReadDeviceRegisters((uvint32_t*)0xE0055010, 1, &reg_data_1);

status = CyU3PReadDeviceRegisters((uvint32_t*)0xE0055014, 1, &reg_data_2);

The reg_data_1 and reg_data_2 would contain the value of the 64-bit unique ID and you can use it according to your application.

Then, does it continue up to 512KB from there?  So I can't use 0x0 through 0x20000?

--> Actually, the size of the image varies from firmware to firmware and you shouldn't overwrite any part of the EEPROM that contains the firmware image burned.
To know the final image location, you can open any firmware in hex editors (HxD Editor) and make sure that you write to a location after the finish of the firmware image.

NOTE: Any over-writing in the EEPROM image location can cause the device to reset or behave unexpectedly and so, any kind of over-writing should be avoided in the EEPROM or FLASH.

Regards,
Yashwant

View solution in original post

3 Replies
YashwantK_46
Moderator
Moderator

Hi Greg,

encrypting the bitstream of an I2C EEPROM to prevent duplication or reverse engineering

--> Can you please elaborate on how you would want to implement this encryption of data?

The above statement and this statement of yours contradict each other, "I am using SPI in my application so I can't use an SPI EEPROM".

--> Can you please confirm on what you would actually want to use? Is it going to be SPI FLASH in the final application for encryption of data?

I would like to use the Windows class driver for a virtual com port, so I don't think I can do a USB boot using a custom driver

--> Please elaborate on your application and how the driver is going to link up with the encryption?

Just couldn't get a clear understanding of the requirement yet.


Please elaborate the above.


Regards,
Yashwant

0 Likes
GrHa_3282776
New Contributor

I would like to write the Unique ID from the FX3 into the I2C EEPROM using an application at the vendor to prevent easy duplication.  I found the Unique Registers from here:

I am booting from the I2C EEPROM also, so I need to know which memory address are available for general purpose reading / writing.  The Programmer manual says it reads address 0 on the peripheral device and checks whether a valid firmware header is received.  Then, does it continue up to 512KB from there?  So I can't use 0x0 through 0x20000?  Any other addresses to worry about?

0 Likes
YashwantK_46
Moderator
Moderator

Hello Greg,

You can go ahead and use the registers mentioned in the above thread which mentions:

The unique ID is actually stored in two registers each of 32 Bit.

  

Their address : 0xe0055010 and 0xe0055014.


You can read these registers by declaring two 32-bit registers as follows:

uint32_t reg_data_1;

uint32_t reg_data_2;

and using the following line to read each 32-bit register as follows:

status = CyU3PReadDeviceRegisters((uvint32_t*)0xE0055010, 1, &reg_data_1);

status = CyU3PReadDeviceRegisters((uvint32_t*)0xE0055014, 1, &reg_data_2);

The reg_data_1 and reg_data_2 would contain the value of the 64-bit unique ID and you can use it according to your application.

Then, does it continue up to 512KB from there?  So I can't use 0x0 through 0x20000?

--> Actually, the size of the image varies from firmware to firmware and you shouldn't overwrite any part of the EEPROM that contains the firmware image burned.
To know the final image location, you can open any firmware in hex editors (HxD Editor) and make sure that you write to a location after the finish of the firmware image.

NOTE: Any over-writing in the EEPROM image location can cause the device to reset or behave unexpectedly and so, any kind of over-writing should be avoided in the EEPROM or FLASH.

Regards,
Yashwant

View solution in original post