问题
I need to output the on-chip buffer (ETB) execution trace in some particular cases. I'm talking about an operational functionality, not about ETM trace during debugging phase.
I've read Arm® CoreSight™ ETM-M7 Technical Reference Manual but there is almost no detail about using this ETB feature.
There is also this link on ARM Information center, but I found it particularly unclear.
How can I use ETB ?
EDIT: I clarified a little bit the situation thanks to a presentation from STMicro. It states that "The ETF can be used as a trace buffer for storing traces onchip. The trace can be read by software, or by the debugger, or flushed via the trace port. If configured as a circular buffer, the trace will be stored continuously, so the most recent trace will overwrite the oldest. Alternatively, the FIFO full flag can be used to stop a trace when the buffer is full, and hence capture a trace at a particular point in time." So what I need to access is not the ETB but the ETF, which is done through a register (the FIFO is apparently not memory mapped ?)
回答1:
Yes, the CoreSight Architecture and ETM trace are designed to enable this sort of crash analysis, particularly in realtime systems where crashes can be difficult to reproduce and you may not able to have the target device hooked up to an external debug capture device all the time. ETM trace can be completely non-intrusive (except for the additional power consumption cost of having the logic active).
The architecture is quite generic, although each implementation will make different trade-offs about what is implemented. This unfortunately means that the documentation is quite spread-out. You might find this technical overview is useful for context (but not detail).
To achieve the crash analysis, you need to cover the following steps:
Configure ETF in circular buffer mode
Configure ETM to trace everything, with fairly frequent synchronisation
Disable the ETM after a crash (so the buffer is not overwritten)
Extract the trace from the crash (to SD card, for example)
Unpack any wrapping protocol added by the ETF
Decompress the trace (presumably offline)
With a circular buffer, trace decompression can only start from a synchronisation point. The ETMv4 protocol uses variable length packets, and rarely traces a full PC address value. You probably want 4 synchronisation points in the buffer, then only the first 25% is lost.
Trace decompression relies on having the code image which was running - this shouldn't be too much of a problem in this use case.
If you can't buffer far back enough after a crash, it is possible to use the filtering logic in the ETM to exclude any code you know is not interesting. Depending on the nature of any crash, you might want timing information. You can set this with a threshold to get a tick in the trace every 100 cycles or so - trace accuracy for cost, but it might be a great clue.
For programming the ETM, you want the ETMv4 architecture (it uses DWT comparators as 'processor comparator inputs' if you need filtering) and for the ETF I think it will be this technical reference manual. Check part_number in the Peripheral ID registers to make sure you have the right programmer's model.
回答2:
Normally you use the ETB with a hardware debugger that supports ETB such as Segger J-Trace or Keil uLinkPro for example. It is something normally for the tool vendor to worry about and not directly usable within your application.
The necessary trace pins (TRACED0 to TRACED3 and TRACECLK) need to be available on your debug header, and not multiplexed to some other function by your application.
The STM32H7 Reference manuals contain a whole section on the "Trace and debug subsystem" (you have not specified the exact part, so you'll have to find it yourself). But in the RM0399 for STM32H745/755 and STM32H747/757 I am looking at it occupies over 100 pages of the manual.
来源：https://stackoverflow.com/questions/58220113/use-execution-trace-on-chip-buffer-etb-on-stm32h7