Forum Discussion
System Console master_read_memory fails above 7688 bytes on Agilex 5 (AXE5-Eagle)
Thank you for looking into it.
The whole design is shared above in the opening post.
also, I see the same issue on any and all images I have built. Were you able to reproduce this? Just download the sof below, and run the commands provided
- Bitstream: axe5_eagle_voltage_temp.sof from https://github.com/ArrowElectronics/Agilex-5, path images/promo3/, md5 b391b9cd5226fe92fd2068ddc66f8442
- That bitstream was built with Quartus Prime Pro 24.3 and reports "HPS present: FALSE", so it configures straight over JTAG with no bootloader merge and no HPS involvement. It exposes a Nios V node and a JTAG PHY
Hi covfefe,
Thank you for the detailed information and reproduction steps.
We attempted to reproduce the behavior on our side. Since the .sof file is provided by Arrow, we do not have visibility into the internal design implementation and therefore cannot verify on the design architecture or memory-map configuration.
To investigate further, we tested with the following reference designs:
https://docs.altera.com/r/example-designs/842176/24.3.0/agilextm-5-system-console-getting-started-design/introduction
Using the following commands:
set m [lindex [get_service_paths master] 0]
open_service master $m
set data [master_read_memory $m 0x0 7689]
puts "Number of values: [llength $data]"
puts "Expected 7689: [expr {[llength $data] == 7689}]"
master_read_memory $m 0x0 7689 completed successfully and returned 7689 values:
Number of values: 7689
Expected 7689: 1
Based on this test, we were able to issue and complete a master_read_memory transaction of 7689 bytes successfully.
Could you please try on example designs mentioned above?
Feel free to let me know the outcome of your testing, and I will be happy to investigate further.
Thank you.
Regards,
ZiYingE_Altera
- covfefe6 minutes ago
Occasional Contributor
Hi ZiYingE,
Thank you for testing. We ran your System Console Getting Started Design (842176, 24.3.0) on our board. It fails at exactly the same byte.
The design ships for the 065B Premium Dev Kit (A5ED065BB32AE6SR0, 50 MHz clock on BM71). We changed only the device to A5ED065BB32AE4SR0 and moved the clock to the Eagle's 25 MHz oscillator on A23. Quartus 26.1.1 upgraded the IP with its parameters kept. The JTAG master and the 64 KB on-chip RAM at 0x0 are unchanged. The design meets timing.
Results on the AXE5-Eagle with the on-board Arrow USB Blaster (ARA40118-TEI0004), Quartus Prime Pro 26.1.1 build 130, one fresh System Console process per read:
- master_read_memory 4096 and 7688 bytes at 0x0: all values returned in 0.0 s.
- master_read_memory 7689, 8192 and 16384 bytes at 0x0: "This transaction did not complete in 60 seconds. System Console is giving up."
- JTAG clock at 6, 15 and 20 MHz: the boundary stays at 7688/7689.
- The Arrow promo3 example and our own design give the same boundary.
So the design is not the difference. Could you tell us which board, cable and host OS you used for your test? Our guess is the difference is the Arrow on-board USB Blaster versus an Altera USB-Blaster II/III. If you have an AXE5-Eagle, or another board with the Arrow blaster, could you try it there?
We are also happy to run any build or debug option you suggest. A System Console log setting would be useful.
Regards,