search

rtic-scope / cargo-rtic-scope

Non-intrusive ITM tracing/replay toolset for RTIC programs with nanosecond timestamp accuracy.
16 stars 4 forks source link

Document and file target-side SWO transients woes, ETB usage #119

Closed tmplt closed 2 years ago

tmplt commented 2 years ago

From a Teams chat:

Some notes from today's experimentation: on device start we configure PC27 to SWO. This yields effectively random noise on the pin which screws up the state of the ITM decoder. Hence why I've gotten a different trace each run. Breaking after this setup and then tracing have yielded the below three times in a row (for a single hardware task pended in init):

$ itm-decode /dev/tty
ExceptionTrace { exception: Interrupt { irqn: 12 }, action: Entered }
ExceptionTrace { exception: Interrupt { irqn: 12 }, action: Exited } 
ExceptionTrace { exception: ThreadMode, action: Returned }

Missing from this trace is the enter packet for ThreadMode, but these can be ignored because RTIC always executes in "handler" mode. The above means that tracing a program from device boot (what RTIC Scope has been designed for thus far) is practically impossible unless it is known how many trace bits we should drop (impossible). This is an effect of using the TPIU for trace exfiltration. The solution to this is to use the Embedded Trace Buffer (ETB) which is stored in memory: high-data throughput, but a smaller FIFO queue (dont know if the size is static yet). This will require a debugger to poll messages quickly enough so that we dont overflow the queue.

Sort the above into relevant issues.