dtsl_config_script.py error when starting debug session

Hi Mark

My 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 with
File > New > Hardware Connection, give it a name [Next], then "Add a new platform" ?

Stephen

Hi Stephen,

Same issue with the hardware connection.

Regards,

Mark.

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: 

• There are no peripherals in the Register view,
• It only allows assembler debugging.

 I’m trying a connect only debug session and have specified the symbols files to load.

 Regards,

 Mark.

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

Regards,

Mark.

Hello Mark

Thanks 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 Mark

Thanks 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" 0x20008000

3) 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), or
community.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.

Regards,

Mark.