|
|
Frequently asked questions about the BDM trace capabilities |
Trace Buffer FAQ
How can the Noral BDM unit capture trace data when it only connects to the BDM connector? Does the trace system slow down my target? Why cant I see the operand data in my 5307 trace? What control do I have over the data captured by the trace buffer? How can I inspect the trace buffer when the CPU has hung? How can I speed up the trace buffer analysis? How can I quickly jump to the start/end of the trace display? How can I look at the trace buffer whilst the CPU is executing? How can I make sure the trace buffer always contains a 'SYNC' point? What is a Trace Buffer and why is it good to have one?A Trace Buffer can be thought of as a 'CPU history log'. The trace buffer captures CPU activity and stores it away so that you can look back in time and see what the CPU did prior to an event occurring. If you think about the debugging process you often end up in a situation where you have stopped execution because a breakpoint has fired on some 'bad' event. The next question you are likely to ask yourself is why this 'bad' event occurred. This is where the trace buffer comes in handy - you can look back in time and see the CPU behavior prior to the 'bad' event and hopefully see the cause of it!How can the Noral BDM unit capture trace data when it only connects to the BDM connector?The ColdFire CPU outputs trace data on the 4 x PST and 4 x DDATA pins of the BDM connector.The kind of information output on the PST pins is
"I executed a branch instruction - and took the branch" "I processed an exception" "I took an indirect branch to an address" The kind of information output on the DDATA pins is
Data read/write data - this is optional Debug data written to the DDATA pins via the WDDATA instruction in your program Does the trace system slow down my target?It might do - or it might not! This is not an easy question to answer. It depends on the kind of trace data being output to the PST/DDATA pins. For example whilst the only data being output to the PST pins is the 'I executed the next instruction' state there is no effect on CPU operation at all. However if your code executed a sequence of indirect jumps the CPU may end up stalling whilst it writes the trace data to the DDATA pins. For each indirect jump the CPU must output the new PC value. Now the new PC value is output onto the 4 DDATA pins one nibble per CPU clock. The ColdFire has a 4 nibble buffer behind the DDATA pins and so a single output of a 4 byte PC value will have no effect the CPU. However if the CPU needs to output a new PC value and the previous one is still being output (i.e. the buffer behind the DDATA pins is full) the CPU will stall. Now most code does not execute back to back sequences of indirect jump (or calls) and so this situation is not likely to occur often in a typical target system. There is however another source of data for the DDATA pins and this is the optional tracing of operand data i.e. read/write data from instruction execution. With operand data tracing enabled there is a greater chance of stalling the CPU since much more information has to be output via the DDATA pins.So what does all this mean in practice? Well to provide some reference information we have done some tests on the example program we supply - in particular on the execution time of the FFT routine within the example code. This table shows the timings of the FFT routine with both the instruction cache on and off with varying degrees of trace data being captured.
With traditional bus based capture tools (Logic Analyser/ICE) you must turn the instruction cache off inorder to capture trace data. Note that with the cache turned off the routine ran 72% slower than with the cache on. Requesting the Noral BDM unit and ColdFire CPU to trace code and both read and write operand data only slowed the CPU down by 19% which is clearly still better than having to turn the cache off. Why cant I see the operand data in my 5307 trace?(Assuming you have requested operand data in the trace: see Trace Control Options) On the 5307 any operand data which is sourced or sinked to the on-chip cache does not get written to the DDATA pins. If you must see the operand data in the trace your only option is to disable the cache operation for the required data area. This can usually be done by programming the ACR0 or ACR1 registers to specifically exclude cache operations on a specified memory area.What control do I have over the data captured by the trace buffer?There are two ways of controlling the capture of trace data.
Operand Data Trace. You can specify whether the ColdFire CPU outputs read data, write data or both. Note that it is possible to capture just operand data - without any instruction trace data but it would be difficult to make sense of the trace display. WDDATA Instruction Data Trace. In this mode the trace buffer captures the output from the WDDATA instructions contained in your target program. In effect this lets you write application specific data into the trace buffer which may then be dumped to a disc file for analysis by another program. How can I inspect the trace buffer when the CPU has hung?What do we mean by 'hung', well it may be that the CPU is not responding to the break request i.e. flex says the CPU is executing but seems to ignore the pressing of the Stop toolbar button. Or it may mean that the CPU stopped but all attempts to access memory fail (probably with red shading in the memory window). In such cases you need to see what is in the trace buffer to find out what was going on prior to the fault. Here is how you should proceed.
Now you must get the CPU back working. This will probably need you to issue a CPU reset (Run | Reset | Hard). You must now restore the target environment which basically means getting all the chip-selects/DRAM setup and you target code downloaded. Note that during the trace buffer analysis phase flex may require access to the target object code - and so the object code must be accessible and identical to that prior to the crash. The Trace Listing Window should now be able to analyse (build) the trace display data. How can I speed up the trace buffer analysis?During trace buffer analysis (sometimes termed 'building the trace') flex needs to read the object code from the target system. The speed at which target memory can be accessed ends up limiting the speed for the trace buffer analysis. This problem can be circumvented by flex holding a copy of the target object code locally within the host PC memory. This may be configured using the Trace Control Options Code Cache tab. This lets you setup address ranges which are captured and held within PC memory during the code download process. Flex then has fast access to the object code within these address ranges whilst analysing the trace.Do not try to use this feature if you code is self modifying or it is modified by some other bus master after being download though flex. How can I quickly jump to the start/end of the trace display?Use the HOME, HOME, HOME key sequence to jump to the start of the trace display.Use the END, END, END key sequence to jump to the end of the trace display. How can I look at the trace buffer whilst the CPU is executing?With the Trace Listing Window opened check that there is data in the BDM trace buffer. Now disable the trace by removing the check on the Enable check box on the windows control bar (the Trace LED on the BDM unit should go out). You can now select Build Trace from the windows local menu.For the 52xx series of ColdFire CPUs make sure you have enabled dynamic memory access (BDM Control Options, Dynamic/HW Break tab) otherwise the trace analysis process will not be allowed access to the program object code in the target system. When you have finished inspecting the trace display you may re-enable the trace buffer to capture further trace data. How can I make sure the trace buffer always contains a 'SYNC' point?In general you cant. However if your target has a periodic timer interrupt which fires often enough this will generate a sync point in the trace buffer. The BDM trace buffer is 1MB long with one byte being captured every CPU clock. So even at 66MHz the trace buffer captures a time interval of 15ms. In this case if your target program generates a timer interrupt every 5 ms (say) you will always have at least 2/3 of the trace buffer following a sync point.If real time execution is not important to you one option is to set
the trace buffer to break each time it gets full. Since flex knows where
execution started from it can generate a pseudo sync point at the start
of the trace buffer. This means that the complete trace buffer is always
analysable. You can then keep executing your target in real time 'chunks'
until the event you are interested in has occured. The complete trace buffer
will then be available to you for inspection.
|
|
| Return to Application Notes Menu Page | top
of page |
|
|
|
