TPIU hardcoded addresses

[tarek-bochkati]

I was just passing by, felt curious about the code, so I jumped in, and ...
I encountered this issue in ./support/gdbsupport.init

in this line https://github.com/Marus/cortex-debug/blob/master/support/gdbsupport.init#L4
(this applies to all gdb commands related to ITM/SWO)
all addresses assumes that TPIU base address is always the same for all the devices, but no
you can refer to STM32H74xx as an example where SWO and TPIU are at different addresses (0xE00E3000, 0xE00F5000)

there is an ongoing work for openocd to fix that as well : http://openocd.zylin.com/#/q/topic:tpiu

[haneefdm]

Yes, this especially concerns multi-core MCUs where there could be a level of indirection. You have to read the ROM tables to figure out SWO/TPIU addresses. Not sure how to fix it.

[Marus]

This is an interesting one, but is certainly a good enhancement candidate to improve support for some devices. As while most devices do use the default location - there are those that don’t (seems especially common for multi-core devices like @haneefdm mentioned).

I will look into this. We should be able to get the addresses needed from the ROM table - the trick will be getting that value into the custom GDB routines defined in the gdbsupport.init file. Might be possible to use a GDB variable within those routines in which case it shouldn’t be to much to support. If not might have to be some sort of solution where it generates an appropriate gdbsupport.init file dynamically before it gets sourced by GDB.

Another option might be a further enhancement to the device support packs that allows them to provide the appropriate support routines file, although this does create additional possible maintenance.

I’ll do some digging and see what I think the best approach will be.

[haneefdm]

At least for OpenOCD, we can execute a script that tells us where the TPIU/ITM/DWT is located (and other CoreSight components. You can also read them from stdout of most of servers.

[haneefdm]

See #571