Small bugs in the ETM trace notebooks (DesignStartTrace repo)

I tried out the ETM trace triggers and PC annotate, ETM both via SWO (CW308 STM32F303) and parallel (CW308 K82F) and noticed few bugs, likely copy&paste/recompile, orbuculum changing around option letters accross versions.

Out-of-sync adresses can be caused because DesignStartTrace is not a submodule of CW repo, so random clones can sync them out (seeing the addresses got updates in log, thinking maybe something like pyelftools could make address retrieval work better than changing it in repos or doing submodule syncs).

  • CW Husky
  • CW version: commit 534fe4881bb54723eb43df465cc54b406d9ccc4f
  • CW DesignStartTrace version: commit 10ef139f248c445e0a1d815ef8af6d1b38f68dfa

TraceWhisperer.ipynb

  • K82F has one address wrong for the precompiled binary in trace.set_isync_matches, 0x3ef0 is right for SubBytes, but AddRoundKey should be 0x3eb8, not 0x3f1c (using the precompiled simpleserial-trace-CW308_K82F ELF/HEX in CW repo). Doesn’t really affect the demo so much, but the graph looks a bit weird then
Reading symbols from simpleserial-trace-CW308_K82F.elf...
>>> p AddRoundKey 
$1 = {void (uint8_t)} 0x3eb8 <AddRoundKey>
>>> p SubBytes 
$2 = {void (void)} 0x3ef0 <SubBytes>
  • orbuculum invocations has parameters like -P that are in none of my orbuculum builds (old one, v2.0.0, some devel version); -e changed for -E to make things more confusing

pc_sample_annotate.ipynb

  • notebook tries to program simpleserial-ecc in fw_path, not simpleserial-trace (then shows incorrect assert when looking at it later in trace.get_fw_buildtime())
  • same thing with orbuculum as above, v2.0.0 switches are different and none of my versions I had over time has -P

But anyway, pretty good job considering how PITA whole ETM trace is to implement and debug, route and connect correctly :fireworks:. I was surprised it worked with parallel trace and my wonky wiring (1.27mm header reduction to 2.54mm header, then to USERIO header, even though I tried to keep all wires aligned).

Thanks for the notes, I will make the corrections! Looks like I inadvertently grabbed the ShiftRows address instead of AddRoundKey.

Looks like Orbuculum has moved forward quite a bit since I last had a look. I can’t seem to get it working the way we use it with the latest release; I’ll have to play around a bit more and will report back when I have an update.
In the meantime this is the version that we used for our development and testing:

A quick check shows that their 1.13 release also seems to work fine with how we use it.

In the 2.0 series, the functionality we need from orbuculum has moved to their orbfifo executable. I thiunk the correct incantation should be:
orbfifo -t 1 -E -P --input-file raw.bin

but there are some issues.

1 Like