Debug configuration in Arm Development Studio v2023.1

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. 

Hi

My 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 helps

Stephen

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-jtag


Stephen

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

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

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

Hi Stephen,

I have managed to set peripheral description file in debug configuration.

And I can access peripheral registers now

But I have no idea why GPIO registers are still Unavailable.


Best Regards,
Naresh

Hi again

Those 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-down
the peripheral might need to be explicitly enabled before use
the 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 access
the peripheral might not be at the address that the debugger thinks it is at

I 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 width

output /x *(unsigned int *)0xFFC02900 # force a 32-bit read

output /x &gpio0_gpio_swporta_dr # prints the address that the debugger knows

output /x gpio0_gpio_swporta_dr # reads from that address

Hope this helps

Stephen