Hi,
I am working on TSoM Cyclone V development kit with Arm Development Studio v2023.1.I have setup Debug configuration according to intel user guide.Unfortunately, I am unable to establish connection and below error pops up after few secs of clicking "Debug"I am sure that my PC detects JTAG interface via USB Blaster ||I have tried the fix suggested in post Arm development studio 2024 altera_debug_server.py error detected - Arm Development Studio forum - Support forums - Arm CommunityIt didn't help to fix the connection and same error pops up.Restarting IDE also didn't help to fix the connection.Is there anything am I missing in the debug configuration ?Best Regards,Naresh
I have just tried detecting Cyclone V using Quartus Programmer and it worked.So there is definitely something wrong either in debug configuration or Arm tool chain.Please note that I am using built in Arm compiler v6.21.
HiMy name is Stephen and I work at Arm.Sorry to hear that you're seeing "The script file ( altera_debug_server.py ) failed during execution".Does the Target Console view give any more information? If not there, try the Error Log view, or look in the ".log" file in the .metadata folder of your Eclipse workspace.The "rddidap_serverd"/"rddi_serverd" naming bug in Arm DS 2024.0 (that was fixed in 2024.0-1) didn't apply to your 2023.1, so that "workaround" wouldn't have worked anyway. I suggest you revert your changes for that.
Other folk have been able to use USB Blaster II with Arm DS successfully - see e.g. the end of:
https://community.intel.com/t5/Intel-SoC-FPGA-Embedded/ARM-DS-USB-BLASTER-or-USB-BLASTER-II/m-p/1597849
Are you able to try updating to the latest Arm DS 2024.1?
If you need more with the Intel platforms, then please try the Intel forum at:
https://community.intel.com/t5/Intel-SoC-FPGA-Embedded/bd-p/soc-fpga-embedded-development-suite
Hope this helpsStephen
Hi Stephen,After updating ARM DS to v2024.0-1 debug server error is fixed.But I am getting below error now.Do you think patch version should work ?Best Regards,Naresh
Hi again
Glad to hear that you've made some progress by updating to Arm DS 2024.0-1. Are you able to update to the latest Arm DS 2024.1?
The error message suggests that JTAG is not enabled on the connector. Boards sometimes have a switch or jumper to select between JTAG and USB Blaster. Suggest you check how the selection is done on your board.
Sorry, I'm not familiar with the Cyclone V platform, but other users have reported seeing the same "NCONT ERROR in ACK for access 0 : ACK = 0x01" before.
Please take a look at:
https://community.intel.com/t5/Intel-SoC-FPGA-Embedded/NCONT-ERROR-in-ACK-for-access-0-ACK-0x01-when-trying-to-connect/m-p/1532754
https://community.intel.com/t5/FPGA-SoC-And-CPLD-Boards-And/NCONT-ERROR-in-ACK-for-access-0-ACK-0x01-in-ARM-DS/m-p/1655422
https://community.arm.com/support-forums/f/armds-forum/49477/ncont-error-in-ack-when-running-debug-on-de10-nano
https://community.arm.com/support-forums/f/armds-forum/55179/ncont-error-in-ack-for-access-0-ack-0x01-when-trying-to-connect-with-arm-ds-debugger-through-jtagStephen
Hi Stephen,
I am able to connect to board now with on-chip ram as application entry point from BootRom(without Preloader).But still boot from SD Card doesn't work for me.I am planning to try some procedures suggested by people in Intel forum to fix that.Another issue is that the peripheral registers are not accessible in "Registers" window but Core registers are.Do you know which configuration to verify to make peripheral registers accessible in "Registers" window ?
Best Regards,Naresh
I have managed to set peripheral description file in debug configuration.And I can access peripheral registers nowBut I have no idea why GPIO registers are still Unavailable.Best Regards,Naresh
Hi againThose peripheral registers are memory-mapped, so the debugger must read from their memory locations to obtain their contents.
"Unavailable" is shown in this case where the debugger tried to read memory from that address, but failed for some reason.
There may be several different reasons why the debugger was unable to read those addresses, for example:the peripheral might be powered-downthe peripheral might need to be explicitly enabled before usethe peripheral might be disabled for the current processor mode or security state (e.g. some peripherals are only accessible in secure state)the peripheral might require a certain access width, e.g. 8-, 16- or 32-bit accessthe peripheral might not be at the address that the debugger thinks it is atI guess, for example, that gpio0_gpio_swporta_dr resides at either 0xFFC02900 or 0xFF708000, but maybe it is somewhere else.I suggest you check Intel's documentation to confirm its exact location and accessibility, then try in the Commands view commands like:output /x *0xFFC02900 # read using default access widthoutput /x *(unsigned int *)0xFFC02900 # force a 32-bit readoutput /x &gpio0_gpio_swporta_dr # prints the address that the debugger knowsoutput /x gpio0_gpio_swporta_dr # reads from that addressHope this helpsStephen