Forum Discussion
FabianL
Occasional Contributor
1 month agoHello Farabi,
- I when data somewhere in between the bitstream the CRC Fallback mechanism works as expected. But that does not solve our problem when somethng goes wrong at the end of the bitstream.
- I checked the last 576 Byte of the RPD file and the flash contents. They actual do match.
- The last 2664 Bytes of the RPD are 0xFF
- Same applies for the Flash memory
- I also compared multiple RPD files (same FPGA Target 10AX027E3F29E2SG)
- The end of the RPD always terminates with a sequence of 4 Byte 0x6A followed by multiple 0xFF Bytes.
- The last 576 Bytes of the RPD always show 0xFF as content
- The absolute number of 0xFF Bytes varies between 2664 and 1616 Bytes (could be other values as well, I only analyzed 8 different bitstreams.
- ==> Giving that I have no glue how to validate the last 576 Bytes and do not know what it should be (except 0xFF)
- I just checked the newest Datasheet of the Remote Update IP core in 1.3.1. Remote System Configuration Mode d(Version 2024.07.25) has a new NOTE compared to Version 2022.08.16
If the first 1024 bytes and the last 576 bytes of an encrypted application imagebitstream are corrupted. Intel recommends that you examine the first 1024 bytesand the last 576 bytes of the encrypted application image before triggering theapplication image configuration.
- This section does not make sense, as it is already included in the previous claim, that Fallback won't work if the last 576 Bytes are corrupted. Unless it is intended to be an OR combination, i.e. the Fallback won't work if the first 1024 or the last 576 Bytes are corrupted.
- Could you please clarify this!
For being able to validate the first 1024 & last 576 Byte of the Bitstream we have to know how the should look like.
Thanks for your assistance.
best regards
Fabian
Farabi
Regular Contributor
1 month agoHello Fabian,
"I when data somewhere in between the bitstream the CRC Fallback mechanism works as expected. But that does not solve our problem when somethng goes wrong at the end of the bitstream."
[ANS] This is known issue where it is the limitation of RSU IP.
regards,
Farabi