Hello all,
Everything was working fine with Arm DS 2021.0.
I have just installed Arm DS 2021.1.
DS 2021.1 will load the workspace / project and build without any problems, but I cannot start a debug session. The error reported is:
Script C:\Users\XXXXXXX\Development Studio Workspace\.metadata\.plugins\com.arm.debug.cmsis\DS-MDK\SAMA5_DFP_ATSAMA5D27\dtsl_config_script.py does not provide configuration DtslScript_DebugAndOnChipTrace.
Any ideas?
Regards,
Mark.
Hi MarkMy name is Stephen and I work in Arm's Development Studio team.There were some changes in this area between Arm DS 2021.0 and 2021.1 that may explain the problem you are seeing. I am investigating this with colleagues and will get back you.In the meantime, as a workaround, have you tried creating a new (non-CMSIS) connection withFile > New > Hardware Connection, give it a name [Next], then "Add a new platform" ?Stephen
Hi Stephen,
Same issue with the hardware connection.
Hi again Mark,We've investigated and identified the problem in Arm DS 2021.1. This occurs for CMSIS-Pack-based connections when the target doesn't have an off-chip trace capability. We'll fix this for the next release.A workaround is to use the ready-made configdb for Atmel > SAMA5D2x, instead of a CMSIS-Pack-based connection - see screenshot. Please could you try this and confirm?Stephen
Hi Stefan,
It can establish a connection to the target, but it is not usable:
I’m trying a connect only debug session and have specified the symbols files to load.
Hi again Mark,Sorry that you are still seeing this problem. Are you seeing any errors in log in the Commands view that might indicate why debug symbols are not being recognized?
I don't have access to a SAMA5D2x, but have tested Arm DS 2021.1 with a (similar) SAMA5D3x, and was able to debug a project at source-level via DSTREAM successfully. It should also be possible to add the missing peripherals from the ATSAMA5D27.svd in C:\Users\XXXX\AppData\Local\Arm\Packs\Keil\SAMA5_DFP\1.1.1\SVD as we discussed before.If you are still stuck, please open a Support Case using the "Support > Open a Support Case" option at the top of this page, so that Arm support and engineering teams can properly investigate.Stephen
Hello Stephan,
I specified the SVD folder in the debug connection and can see the peripherals, but it still won't show me the source code.
I'm going to wait for the next version and use Ozone for now.
Maybe the next version will also fix the terrible debugging performance, for example Connect to Target takes 30 seconds with the new Hardware Connection and a ULINK2 and less than a second with Ozone and a j-link Pro).
Results of the command window:
Connected to stopped target Atmel - SAMA5D2x cd "D:\Projects\..." Working directory "D:\Projects\..." Execution stopped in SYS mode at S:0x26F178C8 file "D:\...\sama5_bare\Debug\zImage.axf" S:0x26F178C8 AND r0,r0,#1 directory "D:\...\sama5_bare" Source directories searched: D:\...\sama5_bare;$cdir;$cwd;$idir quit Disconnected from stopped target Atmel - SAMA5D2x
Hello MarkThanks for sending the commands in the Command view.It looks like you are trying to debug code resident in Flash - correct?When "connecting-only", the debugger just connects. It doesn't set the PC to the entry point of the image.Are you sure that the address 0x26F178C8 corresponds to some code within your image?Try right-mouse-clicking on that address in the Disassembly view, and select "Show in Source".I can reproduce what you see (no source code appearing after loading symbols) if, before loading the image, I deliberately move the PC to an address outside the range of my image. After loading the image, when I move the PC back to within the image, source code then appears as expected.Sorry you are seeing poor connection performance with ULink2. Creating the New Hardware Connection takes some time, but once it is created, you should be able to connect within a few seconds by clicking on the .launch file in the Debug Control view.Stephen
The code is in the DDR RAM, it's copied from an SD card by a bootloader and executed. The software is already running and has logged data via a serial port. I connect to the target and then break execution.
There is code code at the current PC:
.safety_code ro code 0x26f0'3afc 0x150 POST_WDT.o [1] .safety_code ro code 0x26f0'3c4c 0xf48 POST_INTERRUPT.o [1] .safety_code ro code 0x26f0'4b94 0xd8 POST_CLK.o [1]
Right click and Show in Source produces an error:
It takes 30 seconds to connect to the target, not create a new target:
Right click on connection in debug control -> Connect to Target -> Start timer -> wait until Interrupt (F9) button is available -> Stop timer.
It's not just connecting to targets that takes so much time, even single step with 2021.0 is slow compared with Ozone and a j-link.
Hi again MarkThanks for the screen shot. The debugger cannot find any source code corresponding to that address.Some reasons why that might happen are:1) There is no debug information in the .axf for that address. Please check that you are compiling with "-g" to generate debug information, and the debug information is not being stripped out accidentally as part of the build. Which compiler are you using, e.g. Arm Compiler 6 (armlang) or GCC? You can check that the ELF executable contains DWARF debug information corresponding to those addresses with AC6's fromelf or GCC's objdump tools.e.g. fromelf -g zImage.axf: 000640: Header: size 0x216 bytes, dwarf version 4, abbrevp 0x21, address size 4 00064b: 1 = 0x11 (DW_TAG_compile_unit) 00064c: DW_AT_stmt_list 0x132 000650: DW_AT_low_pc 0xc0000000 000654: DW_AT_high_pc 0xc0000230 000658: DW_AT_name ..\startup.S 000665: DW_AT_comp_dir C:\Users\xxxx\Development Studio Workspace 2021.1\my_project\Debug 0006c3: DW_AT_producer Component: ARM Compiler 6.16 Tool: armclang [5dfeb700] 0006fa: DW_AT_language 0x8001 0006fc: 2 = 0xa (DW_TAG_label) 0006fd: DW_AT_name Vectors 000705: DW_AT_decl_file 0x1 000709: DW_AT_decl_line 0xa 00070d: DW_AT_low_pc 0xc0000000:2) The code has been relocated from one area in memory to another, but the addresses in the debug information correspond to the first initial area, not the second subsequent destination. The debug addresses can be adjusted by loading the debug symbols with an offset, e.g.file "D:\...\sama5_bare\Debug\zImage.axf" 0x200080003) Is this a Linux image? If so, debug symbols would normally be loaded from the file "vmlinux". Also, if the code has started executing then perhaps the MMU is not yet enabled, so an offset is needed to handle the difference between physical and virtual addresses. The Arm Debugger provides special features for debugging the Linux kernel, for debugging pre-MMU (with an offset) and post-MMU (without an offset). See https://community.arm.com/developer/tools-software/tools/b/tools-software-ides-blog/posts/porting-linux-made-easy-with-ds-5 (older, for Armv7-A), orcommunity.arm.com/.../debugging-the-armv8-a-linux-kernel-with-ds-5 (more recent, for Armv8-A), or https://developer.arm.com/documentation/102021/2021-1/Debug-applications-on-a-heterogenous-system/Debug-the-Linux-Application-and-Kernel/Create-the-Linux-kernel-debug-project (tutorial for iMX7)Stephen
1. The AXF is built with armclang and contains debug symbols. It debugs fine with Arm DS 2021.0 and Ozone.
2. There is no code relocation.
3. It's bare-metal.