Nov 06, 2020
02:40 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nov 06, 2020
02:40 AM
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:
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.
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.
13 Replies
Nov 30, 2020
11:49 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nov 30, 2020
11:49 PM
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
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
Dec 01, 2020
12:57 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dec 01, 2020
12:57 AM
Thanks for the reply teoBits.
I tried 1.2.4 but there's no improvement unfortunately.
I tried 1.2.4 but there's no improvement unfortunately.
Feb 28, 2021
11:49 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Feb 28, 2021
11:49 AM
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.
Feb 28, 2021
11:34 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Feb 28, 2021
11:34 PM
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
Apr 01, 2021
11:22 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Apr 01, 2021
11:22 PM
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.
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.
Apr 02, 2021
01:40 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Apr 02, 2021
01:40 AM
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
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
Apr 05, 2021
11:53 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Apr 05, 2021
11:53 PM
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.
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.
Apr 06, 2021
05:09 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Apr 06, 2021
05:09 AM
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
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
Oct 13, 2021
01:08 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Oct 13, 2021
01:08 AM
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.
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.
Oct 18, 2021
06:06 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Oct 18, 2021
06:06 AM
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.
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.
Oct 19, 2021
08:36 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Oct 19, 2021
08:36 AM
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.
- 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.
Nov 30, 2021
08:11 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nov 30, 2021
08:11 AM
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.
Jul 24, 2023
03:20 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jul 24, 2023
03:20 AM
Same happens also with our project. Any updates since 2021?