Time to bring back Runtime TAD (Task Aware Debugging) EDS Client

[pmt]

For many years MQX offered a great tool called TAD/EDS Client.  This allowed kernel aware inspection of MQX kernel structures at run-time over a serial or Ethernet link (TCP or UDP).  There really wasn't much to it, but it was simple and an extremely useful tool. 

This seems to have withered with the Freescale MQX releases and I don't know why.  The only task aware debugging available is through JTAG/IDE which doesn't cut it in many situations.  You can't always have a debugger connection to a tool.  Of all the effort put into improving and enhancing Freescale MQX this would be the biggest bang for the buck.

There is crude shell support in MQX in a module called tad.c.  This allows task, stack and lw memory listing into the telnet shell.  Even expanding this to the features contained in the old client would be fantastic. 

PLEASE PLEASE Bring this back!  Why did MQX drop support for this utility?

PMT

[pmt]

Ok, so I figured out this still exists but the MQX Runtime client only exists as a Codewarrior plugin.  Any chance that this get released as a standalone, or as part of KDS?

PMT

[RadekS]

TAD is still active tool and you can use it together with some of IDEs.

TAD is available as plug-in for CW and KDS trough update sites - Help/Install New Software…

TAD is already build-in in IAR.

MQX also contain installation file for TAD under Keil IDE.

Please look at c:\Freescale\Freescale_MQX_4_1\doc\tools\ and open document according your IDE. There you can find information how to install/use TAD tool.

Have a great day,
RadekS

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[pmt]

Radek,

Thanks, but I'm referring specifically to Runtime TAD, not TAD through a hardware debugger.  I.E. the client that talks to 'eds.c' module in RTCS over Ethernet. 

It looks like the Runtime TAD is only supported in CW.  So any chance of getting this in KDS, or as a standalone client?     

[RadekS]

You are right - my fault.

Runtime TAD is available only for CW currently there isn’t any plan for next development or implementing to other IDEs.

Runtime TAD is cool, but it has also some limitations. It cannot work with large amount of data, stack usage,… because it has to effectively stop CPU and this isn’t really “Runtime”. Additionally due to time delay trough information transfer you cannot be sure that you see real values what are currently in MCU.

[pmt]

Radek,

KDS is your new platform and it would be sorely missed.  I don't understand why this tool would not be supported.  Are you giving up on Ethernet because only a limited number of Kinetis devices support it?  If so you might as well drop support for RTCS. 

"Stoptime TAD" (hard debugger connection) has serious limitations, not the other way around.  It stops the CPU and you need a physical JTAG connection.  You can't always get a physical JTAG connection if you device in embedded in a housing, or is half way around the world.  That's the whole point of Runtime TAD.  It may not be useful to you, but if you ever had to deploy a networked device into the field you would understand.  This is the closest thing to a 'gdbstub' over Ethernet, and anyone that has used that knows how incredibly powerful that is.

-The point you make about the time delay is always true, even with a JTAG interface.  The values are "real" but everyone understands that they are just a snapshot.  I'm not getting your point about the time delay.

-The point you make about stopping the CPU is not true.  It doesn't stop the CPU, it runs as any other task would run.

-The point you make about stack usage is not valid.  You already have a console function 'tad stack' which runs an executable on the target that scans the stack without actually transferring all the memory values to the client.  It's extremely fast.  Hook it into the TAD server.

Very Disappointed.... What is the proper way to petition for this support in KDS?

PMT

[RadekS]

I guess that main topic of this thread is not about whether Runtime TAD is good or bad tool.

As I already mentioned, I agree that Runtime TAD is great tool.

The fact is that Runtime TAD is specific tool designed directly for CW. Freescale decided to go different way and use open source/free resources as much as possible instead of developing his own proprietary solutions and charge for that … therefore we have KDS – it is free/unlimited tool and we don’t plan upgrade it to a CW copy. Everything is about money…. KDS is tool for free, but it has also some limitation in functionality. It is up to you whether you extend it by additional plug-ins or you choose any commercial solution…

As I already mentioned, current plans don’t contain any points about update/porting Runtime TAD. We registered your demand and if there will be such requests from marketing side, plans could be changed… 

[pmt]

Radek,

Thanks, that is a good explanation. 

The Runtime TAD was historically always a part of MQX going back over a decade.  The client side (PC side) was always a standalone application (probably written in Visual Studio) called EDS Client, and this existed long before Code Warrior.  It was provided to MQX by Precise / Embedded Access. 

Yes, the CodeWarrior port of the client side to the CodeWarrior IDE was certainly done on CodeWarrior's dime.

The server side (embedded side) was always in, and is still in the latest MQX distribution, 4.1.1, and I'm sure that was inherited and now owned by Freescale. 

What has to be developed is a KDS plug-in or standalone application.  This would be very valuable if this could be developed for KDS, but short of that can Freescale release the protocol spec or publish the last source to the old EDS client?  I'm sure there would be takers in the community to bring this utility up to the latest release.

Thanks,

PMT

[macl]

Hi pmt,

Your feedback is excellent.  I agree that this is a gap we need to fill.  We will keep you posted. 

Thanks

Mac