MAX10 RSU not accepting new image

[Bricci]

We have a design on a MAX 10M04SA part with only discrete logic. We are attempting to perform RSU via an I2C interface. The part stores 2 images in CFM0 and CFM1/2 and initially boots from CFM1/2. Using I2C the design writes blocks of data to a RAM then triggers a write from RAM to FLASH. This appears to function as a read back from flash matches the data written.

Once all the blocks are written to the flash RSU is triggered with logic in the verilog file attached, which comes from an Altera example. We are finding that the device always reboots to the factory image stored in CFM0 instead of the new image in CFM1/2.

The CONFIG_SEL pin has an external 10K pullup.

some questions we have

- Is there any logic missing from the attached file?

- Is there any way to find out why CFM1/2 is not being used such as a CRC error?

- Does Enable CONFIG_SEL pin option need to be checked in the device and pin options general tab?

- The file loaded over I2C is the rpd file generated from the convert programming files tool, does this need any post processing or CRC to be appended?

[YuanLi_S_Intel]

Please find my response below:

-Is there any logic missing from the attached file?

Can you try to read status and see if you could get anything?

-Is there any way to find out why CFM1/2 is not being used such as a CRC error?

There is a CRC_Error pin, you can check the status from there.

-Does Enable CONFIG_SEL pin option need to be checked in the device and pin options general tab?

Only the setting is needed in Initialization Configuration Bits.

-The file loaded over I2C is the rpd file generated from the convert programming files tool, does this need any post processing or CRC to be appended?

No, not needed. When you perform remote update, it will check the CRC ERROR itself and if there is any issue, it will revert back to factory image.

[Bricci · Accepted solution]

For anyone interested there were two small independent issues.

1. The rpd file generation tool has an endianness option buried in it. We needed to change from the default little endian to big endian. The unusual part is the setting changes bitwise endianness within a byte instead of word wise endianness order of the bytes. We figured this out from readback of the flash over JTAG as readback over I2C would return the data we wrote without the bitflip but it could be seen comparing before and after pof files in a hex editor.
2. The RSU block from older example code has an active high reset when the rest of our system has active low. The block was always in reset so didn’t return any debug information to us to help with the flash issue.