FakhrulA_altera
Regular ContributorJoined 3 years ago
User Profile
Regular Contributor
User Widgets
Contributions
Re: A5EG013BB18A OPN is visible in Quartus but not listed in Program File Generator
Hi, This issue is somehow related to this thread: https://community.altera.com/discussions/fpga-device/can-not-program-agilex-5-device/350661 Can I confirm that you able to generate the programming file using that OPN in Quartus 25.1? Regards, Fakhrul25Views0likes3CommentsRe: Securing device: How to disable JTAG port?
Hi, For Cyclone V SoC, the JTAG pins are dedicated pins connected to the device’s TAP controller, so they cannot be reassigned as normal user I/O. This is why they are locked in Pin Planner and do not appear under Dual-Purpose Pins. For production security, the recommended method is to use the device’s Design Security features, in particular: JTAG Secure Mode encrypted configuration/programming If physical access also needs to be blocked, this should be done at board level, for example by removing or isolating the external JTAG connection. Please refer to Cyclone V Device Handbook Volume 1, Chapter 7: Configuration and Design Security, especially the sections on JTAG Secure Mode and Design Security Implementation Steps. Regards, Fakhrul21Views0likes0CommentsRe: ES vs Production SOF
Hi, The error is due to a JTAG ID mismatch between the SOF and the actual silicon. Most likely due to a JTAG ID mismatch caused by ES vs Production silicon revision, not a random JTAG readback issue. The SOF expects ID 0x4364F0DD while the device reports 0x0364F0DD. This difference typically indicates an ES versus production silicon variant mismatch. Quartus performs a strict ID check before programming, and this validation cannot be disabled or bypassed in System Console. This is not a JTAG read issue. It is a device targeting mismatch between the compiled SOF and the detected hardware. Recommended action: Recompile the design using the correct device variant that matches the silicon on your board Ensure the Quartus device selection aligns with the actual JTAG ID being detected Once the device and SOF match, programming should proceed normally. Regards, Fakhrul6Views0likes0CommentsRe: Has the 5AGXFB7K4F40I3G updated the process to replace the steel lid with the glass lid after 2021
Hi BXion2, Thanks for your question. This thread has already been closed, so it may not get the attention needed for a proper response. Would you mind opening a new thread for this? That will help the community and Altera team track and respond more effectively. You can reference this thread in your new post for context. In your new thread, it may help to include: Date codes and lot markings of the devices you observed Source of purchase, if known Photos of the package lids if available The package drawing link you are comparing against This will make it easier for others to provide accurate guidance. Appreciate your understanding. Regards, Fakhrul11Views0likes0CommentsRe: Regarding the issue of UFM not starting
Hi Watanabe-san, Thanks for the update, if both XIP from UFM and “copy to RAM then run” fail, the next step is to confirm whether the CPU is reading valid code from the expected UFM address. Please try these quick checks: 1. Read back UFM content - Run a small temporary Nios app loaded to RAM via JTAG that reads the first 32 to 64 bytes from the UFM base (via the On-Chip Flash IP) and prints them. - If it reads all 0xFF or unexpected data, the issue is UFM programming or placement. 2. Confirm address alignment - Compare: Nios reset vector address, linker map .text start address, and the HEX placement used in Convert Programming File. - Any offset or page mismatch will prevent boot. 3. Confirm UFM access and wiring - Ensure UFM sector is not Hidden and is readable in the On-Chip Flash IP settings. - Ensure the Nios instruction master can access the On-Chip Flash memory interface and clocks/resets are correct. Regards, Fakhrul5Views0likes0CommentsRe: Regarding the issue of UFM not starting
Hi watanabe, Thanks for the details. From my understanding, if CFM programming is working but the Nios II software in UFM does not start, the most common causes are below. Could you please check: Boot method match: Confirm whether you are using XIP (execute-in-place) from UFM or a boot copier that copies the app from UFM to RAM. If the system is set for boot copier but only the app HEX is placed at the reset address, the CPU will not start correctly. Reset and exception vectors: Ensure the reset vector points to the exact UFM address/page where the code starts. A page or offset mismatch will look like “no boot”. Try refer UBooting with dual compressed images on a MAX 10. Dual Compressed Images behavior: In Dual Compressed Images mode, on-chip RAM preload is disabled. If your flow depends on RAM being pre-initialized at configuration time, it will not work in this mode. UFM placement for multiple images: If you are trying to keep two software images in UFM (aligned to CFM0/CFM1), you may need an explicit offset strategy and a combined HEX approach, not two separate HEX files. Regards, Fakhrul15Views0likes3CommentsRe: Trying to reach an EPCQ128A thought Cyclone V dedicated pins, after FPGA loaded in FPPx32
Hi AMass, From my understanding, yes, you can keep MSEL at FPPx32 and access the EPCQ128A in user mode, but not via the HPS GSFI on the AS‑dedicated pins. Those pins aren’t driven by GSFI, which is why RDID returns 0xFF. Recommended approach: Keep MSEL=0b01010 (FPPx32). Instantiate the ASMI Parallel II IP in the FPGA and expose it to HPS via H2F/H2F‑Lite to read/write the EPCQ. Enable user‑mode access to the AS interface in Quartus (Device and Pin Options). Ensure only one master drives the flash; keep WP# and HOLD# high. If you prefer to use GSFI, the flash must be routed to regular FPGA I/O (or use the HPS QSPI controller). Regards, Fakhrul15Views0likes2CommentsRe: MAX10 RSU upgrade succeeds, but device boots Factory image instead of Application
Hi Vishal, Thanks for the update. The 0x0002B7F0 vs 0x0002B7FF difference is just trailing 0xFF padding. It’s acceptable as long as the flash beyond 0x0002B7F0 remains erased (0xFF). For safety and consistency, extract and program the full CFM1 range per your .map (0x00008800–0x0002B7FF, inclusive). For firmware‑driven RSU using On‑Chip Flash, please use a CFM1‑only .rpd as the payload (as in step #7). A .pof is a programmer container intended for JTAG/off‑board programming and is not suitable unless your firmware explicitly parses it. Recommended: keep your .tar but include the CFM1‑only .rpd for the RSU path (you may still ship a .pof separately for lab JTAG, if needed). Please: Erase and program exactly 0x00008800–0x0002B7FF. Verify after write. Set the Remote Update boot address to the Application start page (convert 0x00008800 to page units per the RSU IP guide) before triggering warm reconfig. Regards, Fakhrul2Views0likes0Comments