AURIX Development Studio Debugger Takes A Very Long TIme to Load .elf File

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Epistemon
Level 2
Level 2
5 replies posted First like received First reply posted
Hello,

I'm using ADS 1.2.2 and connecting to my proprietary target board containing TC277 with miniWiggler over DAP2. Compile and link is just fine.

My problem is that when I launch the integrated (TASKING?) debugger it takes approx. 5 minutes to open the debugger perspective. In the console it looks like it freezes:

Starting Debugger...

Launching configuration: Test
Loading 'I:\Eclipse\ADS\Debug\Test.elf'...


After 5 minutes, once the debugger is launched, it works just fine.

The five minute delay is variable depending on the performance of the PC being used. A slower laptop can take up to 10 minutes.

What is happening during this period please? Flashing the same program with MemTool and miniWiggler takes seconds as usual so doubt it is a slow flashing issue.

Any help to reduce this time would be very much appreciated.


Thanks.
0 Likes
13 Replies
teoBits
Employee
Employee
5 sign-ins 100 replies posted 50 replies posted
Hello,

can you please try with the latest version of AURIX Development Studio? The current version is 1.2.4. You can dowload it from here: link.

BR,
teoBits
0 Likes
Epistemon
Level 2
Level 2
5 replies posted First like received First reply posted
Thanks for the reply teoBits.

I tried 1.2.4 but there's no improvement unfortunately.
0 Likes
User18340
Level 1
Level 1
First comment on blog Welcome! First reply posted
I have the same issues with miniWiggler DAP2 for the elf loading(ADS v1.30), but the memtool flash its hex file with a very short time.
0 Likes
teoBits
Employee
Employee
5 sign-ins 100 replies posted 50 replies posted
If you only need to flash the program in the device and not debug it, you can use the "Flash current project" button in the AURIX Development Studio
4992.attach
0 Likes
User21536
Level 1
Level 1
We see the same behavior in TASKING IDE, TriCore Eclipse IDE v6.3r1 to be precise.
Weird part is that multiple elf binaries are launching just fine (within 30 seconds), but some are not! (Up to 30 minutes).
Noteworthy detail is that, for the very slow binaries, the RAM memory usage increases massively during the "Launching delegate" already (which takes a while too), and then drops a bit before "Loading image from file".
Then increases slowly over the 10 to 30 minutes to actually launch the debugging perspective.

Please come up with a solution or workaround! We actually need the debugging functionality, so just flashing is not a solution.
0 Likes
TBencher
Level 6
Level 6
25 solutions authored 25 likes received 5 questions asked
Hi epistemon and weij,

I have never heard about those problems before. If you have a TC2XX, the miniWiggler and Aurix Development Studio or Tasking IDE, everything should work fine.
I think it is more likely that the problem comes from your software setup or even from your hardware.

Please list your complete software configuration and also provide a partial schematic of your custom board where we can see whether you have a proper debug connection.

Regards,

Jens
0 Likes
User21536
Level 1
Level 1
We are using the DAP MiniWiggler V3, together with the TriCore Exlipse IDE v6.3r1.
Compiler is Tasking v6.3r1.
Microcontroller is the TC333, using debug target "Infineon TriBoard TC33x"
The workspace setup seems to be correct: To rule out the workspace setup I just replaced the application.elf which refuses to load within a normal timefram, with another application.elf that was functional in the past in the output directory.
Launching this old application.elf in the same debugger configuration launches just fine.

P.s. Unfortunately we are not the intellectual property owner of the hardware, and therefore not allowed to share the details.
0 Likes
TBencher
Level 6
Level 6
25 solutions authored 25 likes received 5 questions asked
Hi wej,

that sounds like a configuration issue. Please compare the configuration from the project where you took the running *.elf file from with your current project settings.
Or just create a new project and copy your code into it. For some reason this behavior could also be related to your code. Please comment everything out and watch
step by step until this behavior occurs again. Then you should have the reason for it.


Regards,

Jens
0 Likes
MartinS
Level 1
Level 1
First like received First like given 10 sign-ins
Hi JensM,
I see exact the same behaviour in TASKING TriCore Eclipse IDE. Project is makefile based and compiled with latest TASKING TriCore-VX v6.3r1 p4.

When importing the .elf into IDE for debugging, it takes 6:30 minutes until HW is accessed and flashing begins. During this time, process taskingdebugger.exe is on 100% CPU load of one CPU-cores and utilizes 1.3GB increasing to 1.6GB memory (with an initial peak of 2GB). Flashing itself then takes only 10 seconds afterwards.

But when importing the .hex or .srec (dreived from the same .elf during build) instead, it takes only 7 seconds until flashing begins. And after further 10 seconds actual flashing time, IDE is ready for debugging. In this case taskingdebugger.exe is on minimal CPU usage and consumes only 200MB memory. Unfortunately .hex/.srec allows no source-level debugging, so this gain is more or less worthless.

What is the bottleneck of TASKING IDE with the .elf and why does it take so long for processing and so much memory usage with taskingdebugger.exe?

Regards,
Martin.
0 Likes
Epistemon
Level 2
Level 2
5 replies posted First like received First reply posted
Thanks to everyone that has replied to this thread and sorry for not responding. It seems I do not receive thread reply notifications by email even though I have subscribed, not sure why. Anyway,

Yes, I too see the issue with TASKING 6.3r1 with a delay of around 5 mins. I am using miniWiggler and TC399 Triboard in this case so I think we can probably eliminate custom hardware being the cause.

Since ADS also uses the tasking debugger, we should probably approach TASKING about this rather than Infineon. I shall make some enquiries.
0 Likes
Epistemon
Level 2
Level 2
5 replies posted First like received First reply posted
I got a reply from TASKING which I summarise here. Please don't shoot the messenger!

- It's a known issue.
- The delay is commensurate with the number of debug symbols and the fact that is implemented in Eclipse/Java.
- They are working on a solution.
- A possible workaround is to only produce debug symbols for the the part of the software you want to debug*.

*Although I haven't tested it, it probably means that you need to set the symbolic debug to 'None' for the project as a whole but set the symbolic debug to 'Full' for individual source file(s) you want to debug.
0 Likes
MartinS
Level 1
Level 1
First like received First like given 10 sign-ins

In the meanwhile, TASKING released the VX-toolset for TriCore v6.3r1 patch 5. In the Releasenotes it is mentioned:


TCVX-44510 - Debugger: ELF load and parse hangs - debug session must be aborted

But even worse, parsing the ELF now takes 10:30 minutes (instead of 6:30 on patch 4). And this is absolutely unacceptable.

barna_peto
Level 2
Level 2
First like received 5 replies posted 5 sign-ins

Same happens also with our project. Any updates since 2021?