Poking DBGMCU_CR in enableSAMD5XTRACE

[florolf]

150 added support for setting up tracing on the SAM D5x family. Since I'm currently working on a project that uses such a chip (the SAME53J20A, to be precise) and had a number of strange issues getting tracing to work, this piqued my interest.

Following along, these writes looked unfamiliar:

  # Set number of bits in DBGMCU_CR
  set *0xE0042004 &= ~(3<<6)

  if ($bits<3)
     set *0xE0042004 |= ((($bits+1)<<6) | (1<<5))
  else
     set *0xE0042004 |= ((3<<6) | (1<<5))
  end

There is no DBGMCU_CR on this chip and it's not a term from the ARM docs either. 0xE0042000 - 0xe00ff00 maps to the External PPB (see the ARM Cortex-M4 Processor Technical Reference Manual, r0p1, page 3-39). Indeed, the ROM Tables claim that on this chip, this is where the ETB is instantiated (output by pyocd):

0000685 I AHB-AP#0 Class 0x1 ROM table #0 @ 0x41003000 (designer=01f part=cd0) [rom_table]
0000687 I [0]<e00ff000:ROM class=1 designer=43b:Arm part=4c4> [rom_table]
0000687 I   AHB-AP#0 Class 0x1 ROM table #1 @ 0xe00ff000 (designer=43b:Arm part=4c4) [rom_table]
0000689 I   [0]<e000e000:SCS v7-M class=14 designer=43b:Arm part=00c> [rom_table]
0000690 I   [1]<e0001000:DWT v7-M class=14 designer=43b:Arm part=002> [rom_table]
0000691 I   [2]<e0002000:FPB v7-M class=14 designer=43b:Arm part=003> [rom_table]
0000692 I   [3]<e0000000:ITM v7-M class=14 designer=43b:Arm part=001> [rom_table]
0000693 I   [4]<e0040000:TPIU M4 class=9 designer=43b:Arm part=9a1 devtype=11 archid=0000 devid=ca1:0:0> [rom_table]
0000695 I   [5]<e0041000:ETM M4 class=9 designer=43b:Arm part=925 devtype=13 archid=0000 devid=0:0:0> [rom_table]
0000697 I   [6]<e0042000:ETB CS-400 class=9 designer=43b:Arm part=907 devtype=21 archid=0000 devid=0:0:0> [rom_table]

While I'm still struggling to find the correct piece of ARM documentation for this particular IP (and the chip has known issues regarding the ROM Table content/access, see Microchip document DS80000748T, section 2.7.2 - though this erratum does not seem to trigger in this case), this is suspect. In particular, various members of STM32 family do have a DBGMCU_CR in that particular place, so this might be a copy-paste blooper.

Similarly, the same block appears in enableTM4C123TRACE, while for example the TM4C123GH6PM datasheet (https://www.ti.com/lit/ds/symlink/tm4c123gh6pm.pdf) claims that the region starting at 0xe0042000 is reserved.

@robots am I missing something fundamental here? Otherwise those lines should probably be removed since they poke unrelated locations randomly.

[robots]

Yes you are probably right. Its copy paste error and works for me :-)

I didnt check every line of copied code.

[mubes]

Afaik, dbgmcu is stm32 specific, so it looks like a copypasta that so far has been benign. I'll fix it on main but it just missed the window for 2.2.0 :-(

On Sat, 21 Sept 2024, 14:55 Michal, @.***> wrote:

Yes you are probably right. Its copy paste error and works for me :-)

I didnt check every line of copied code.

— Reply to this email directly, view it on GitHub https://github.com/orbcode/orbuculum/issues/157#issuecomment-2365195810, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABJTBD5EDA4ZZJLX3CSDOTTZXV3DNAVCNFSM6AAAAABOTSXOF6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNRVGE4TKOBRGA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[mubes]

This is fixed in #7eff039. Thanks!