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.
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
Hi 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
Hi Stefan,
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.