Recently, I came to know about ETM(Embedded Trace Macrocell). This is to trace instruction of program to know the bugs. The same can be achieved by ITM(Instrumentation Trace Macrocell) by using printf() statement.We can know the bugs by using ITM also. This is not using any controller ports.
Then what is the importance of ETM? Can anyone tell? I couldn't understand it. Debuggers with ETM are higher in cost. What's the purpose of that?
ITM means you can create a debug channel for sending messages from your code to the debugger.
ETM means that the chip hardware can stream out step-by-step how it walks through the instruction stream. There is heavy data compression involved so it basically just informs the debugger with "y", "n", "n", "y" if it takes jumps or not. This means the debugger on the PC can recreate a virtual copy of the instruction sequence the processor performs.
So you can look back in time and evaluate the instruction sequence that led the program into a specific state.
This is a big advantage if you need to solve issues with magically hanging software, programs making unexpected jumps, getting stuck in interrupt service routines etc.
So ETM is very good when your program performs unexpected crash-and-burn magic. And ITM is good for getting some trace output of the performance of your business logic "config saved", "motor started", "user intervention timeout", ...
You pay extra for a ULINKpro just because it gives an additional professional feature intending to cut down debug times when something is really off and you can't just rely on single-stepping through the program. Single-stepping doesn't work well in a real-time system where the external hardware doesn't stop the time just because you want to stop the time in the debugger.
So ETM is in some ways a flight data recorder (black box) crash protected memory. Expensive but valuable.
Is anyone of you (who are reading this) using Ulinkpro?
ETM is only for instruction tracing or also used for DATA trace?
Someone of KEIL technical persons said ETM is for instruction trace and SWO(ITM) is for Data trace but in "Embedded Trace Macrocell™ ETMv1.0 to ETMv3.5 Architecture Specification", it is telling that ETM is for both instruction trace and data trace. Which one is correct?
In ULINKPro documentation there is given that accurate code coverage and performance analyzing will be given by this Ulink pro debugger. Code coverage and performance analyzer options are already there in KEIL then what extra advantage this ULINKPro debugger is giving?
I have started using SWO (Serial Wire output) which is serial wire tracing. While I am trying this, it only showing the interrupt events and hardfault handler events. Is this really meant for interrupts tracing only. Other than these interrupt executions I couldn't see any other.
Anyone of you please explain the different tracing options and what are the reasons to go to next level.
Without ETM your debugger will never see any instruction trace other than when using the simulator. And the simulator can't simulate a full chip and may not know to add additional clock cycles when the processor core stalls on some I/O or waiting for instructions from the flash.
With other options you may get some background reads of memory content but then you need breakpoints and single-stepping to see what the processor is doing.
Ask yourself a couple of questions:
How much is your time worth? Do you have to single-step your code to understand how it works? Do you have the ability to instrument your code to understand dynamic flow in real-time? Do you have occasion where you need to determine how-on-earth the code got to the point where it crashed?
Trace is a high-bandwidth recording of flow, it generates a lot of data, and the chips/hardware to do it are more expensive than twiddling a JTAG/SWD scan-chain. The software translates this flow information into what is happening within the CPU and memory.
Either you can make a case for it based on a few man-days of your time, or you can't. If you have poor debugging/diagnostic skills it is probably not going to help a lot.
The SWO/SWV can provide instrumentation output, running code can determine if the debugger is attached, and you can output data. The bandwidth is finite.
And, yes I have a ULINKPro and J-Trace pods.
I think all pro developerd should go for a real trace solution. I hardly ever use a debugger and instead rely on instrumented code that is permanently inserted.
But sometimes it's possible to get stuck with some lockup where the real-time requirements doesn't allow instrumentation or single-stepping in a debugger. Then it's good to be able to capture instruction traces.
The cost of the ulink pro is low compared to the Lauterbach units that people many times could only afford to rent for a number of days/weeks.
You are likely operating at a whole different level, and a billable day of your time approaches that of the pod. I remember when a real ICE cost as much as a car, and mechanically challenging to mount in the system.
I see it as being particularly useful when a bunch of people with a broken project show up at my door expecting me to fix it yesterday. But they also likely lack any debug/instrumentation strategy.
Debugging skills are highly valuable.
People who always posts their bugs on forums to get help never gets the chance to learn how to analyze code and by just experience and a bit of thinking be able to fingerpoint with a high probability exactly which function or group of code lines that is likely to produce the unwanted result.
It takes skill to write good code. And it takes skill to debug efficiently.
Lots of jokes about a person just walking up and looking at a screen of code and then point at a bug. But in reality, it's not much different from a traditional code review. It doesn't take many seconds to spot code lines that smells and needs further analysis. The biggest problem is if all code looks like a rat nest - there is no easy way to say that the code might possibly work but should be thrown out or seriously rewritten.
In the end, it's all about having a suitable toolbox. Some tools are just mental - experience from past projects, best practices, memorized check lists. Some are helpful software or hardware. In some cases it might just be the skill of how to describe the problem clearly to someone else - formulating the problem is a major part of solving it.
For some problems, many different tools might work well. For some problems, you really want a very specific tool because it's so much better than the alternatives for that specific problem. Ulink Pro is a tool that is seldom needed but can pay itself quickly for some specific problems.
Ok..thanks for everyone...Ulinkpro is good..I also accept...now I am facing another problem with my KEIL IDE.
To see the trace data we have to use INSTRUCTION TRACE WINDOW but it is not available in my KEIL Vesrion.
KEIL version: MDK-PLUS 5.22
Then how can I see the data..Only trace exceptions and event counters are available.
Is there any need to change any configuration or dll file?
If instruction trace window is not showing then there is no use of using ULINKpro.
Please give solution to my problem (if anyone knows)