Forum Discussion
Occasional ContributorSystem Console master_read_memory fails above 7688 bytes on Agilex 5 (AXE5-Eagle)
ContributorHi 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
Occasional ContributorHi 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,
- ZiYingE_Altera
Hi @covefefe,
Thank you for your patience.
We set up and tested the same AXE5-Eagle board on our side using the on-board Arrow USB-Blaster and were able to reproduce the same behavior you observed.
We then repeated the test on the same board using an Altera USB-Blaster III, and the issue was no longer observed. This aligns with your suspicion that the behavior may be related to the Arrow USB-Blaster.
Would it be possible for you to test your setup using an Altera USB-Blaster III, or any other Altera USB-Blaster available on your side, and let us know whether the issue persists?
Based on our findings, the behavior appears to be specific to the Arrow USB-Blaster. Since we do not have visibility into its implementation, it would be best to engage your distributor or Arrow representative and open a support request with Arrow for further investigation of this issue.
Thank you.
Regards,
ZiYingE_Altera
