Forum Discussion

GordWait's avatar
GordWait
Icon for Occasional Contributor rankOccasional Contributor
1 month ago

Cyclone VGT Dev Kit boards - some new boards failing to boot from NOR Flash

We've been using these boards for years, having certified them for use in one of our products. In the last few months we have now received 5 of these boards and they fail to configure from NOR flash...
Board Debug
Fpga Devkit
FakhrulA_altera's avatar
FakhrulA_altera
Icon for Regular Contributor rankRegular Contributor
1 month ago

Hi,

Thanks for the detailed information and for outlining the debug steps taken.

From our side, there are known changes in the RevB board (including NOR flash device and routing), and there is a related knowledge base article that may be relevant to what you are seeing:

  • Why can’t I access the EPCQ flash device on the Cyclone V GT FPGA Development Kit (DK-DEV-5CGTD9N-B)?
    https://community.altera.com/kb/knowledge-base/why-cant-i-access-the-epcq-flash-device-on-the-cyclone®-v-gt-fpga-development-ki/344352

Before concluding this is the same root cause, could you help confirm a few points:

  1. Are all failing boards confirmed to be RevB, and using the same NOR flash device (Micron)?
  2. Does the issue persist even with the factory image without any modification?
  3. Are you able to consistently program and verify the NOR flash contents via JTAG on failing boards?
  4. Is the retry behavior reproducible across power cycles, or intermittent?

This will help us determine if your case aligns with the known issue or if something else is contributing.

Looking forward to your feedback.

Regards,
Fakhrul

FakhrulA_altera's avatar
FakhrulA_altera
Icon for Regular Contributor rankRegular Contributor
1 month ago

 

Hi,

Thanks for the detailed update, this is very helpful.

Based on your findings, a few observations:

  • Since JTAG programming and CRC verification are clean, the data path from NOR flash to MAX V appears valid.
  • The repeated configuration retries (especially dozens of attempts) are not expected and indicate instability during configuration.
  • The difference between the factory .pof and self-compiled version may point to differences in fitter/timing results.

There is a related KDB which may be relevant to RevB boards with updated device changes:
https://community.altera.com/kb/knowledge-base/why-cant-i-access-the-epcq-flash-device-on-the-cyclone®-v-gt-fpga-development-ki/344352

Although it refers to EPCQ, it highlights a known incompatibility on RevB (U29), which may also affect configuration robustness.

To help narrow this down further, could you also share the following:

  1. For the 3 boards that work with the factory .pof, do they complete configuration in a single attempt or still show retries?
  2. For the 2 boards that still fail, is the retry behavior identical across all images?
  3. Have you compared settings between your compiled .pof and the factory .pof (e.g. compression, configuration options)?
  4. Could you share the serial numbers of the affected boards? There may be a specific affected range for certain revisions.
  5. For the silk screen difference, if possible, please share board markings or photos for comparison.

This will help us check if your boards fall within any known affected batch or if this is a new variation.

Thanks again for the detailed debugging effort.

Regards,
Fakhrul