14:43 <zapb_> karlp, it's a CMSIS-DAP problem, right? Because I successfully flashed a gd32vf103 device

17:02 <zapb_> is there an easy way to determine the cortex-m core type (m0, m3, m4, ..) via Tcl?

17:19 <karlp> zapb_: no, it's an openocd problem, becuase it flashes ok with the same cmsis-dap debugger usingthe riscv-openocd fork.

17:19 <karlp> but I'll dig it more later tonight and see if I can narrow it down.

17:20 <karlp> kinda glad I have a gd32vf103 target to check my basic setup before I get to the more exotic riscv core :)

17:55 <borneoa_> zapb_: when you dump the ROM table with "dap info" you should get something about the core type

18:48 <zapb_> borneoa_, I was thinking about a Tcl command to get this info, would be much easier. What do you think?

18:49 <zapb_> core type and arch type

18:50 <antto> karlp, is that a gdlink programmer?

18:52 <borneoa_> zapb_: what is the use case? Usually this info is needed to write the config file, and dap info should be enough. Then src/target/cortex_m.c need it for internal stuff

18:54 <zapb_> borneoa_, I want to check what core I have to use it for TPIU config

19:00 <borneoa_> zapb_: the topic should be listed in the config file. It can be found from dap info. I started listing all the cortex-m configs to find which need it, but with some I can only guess

19:01 <borneoa_> zapb_: s/topic/tpiu/

19:03 <zapb_> borneoa_, to make it more concrete: I want to add tpiu support for efm32. we have a single config but m0+ devices do not have tpiu. So either we have different configs or have some kind of auto-detection

19:04 <zapb_> borneoa_, IMO dap info is not suitable because it has "human style output" and should not be used for Tcl scripts

19:13 <borneoa_> zapb_: for sure m0 and m0+ don't have tpiu. But tpiu is optional for m3, m4, m7, ... With a single script for many possible CPUs I would suggest to read the ID registers of the tpiu to check if it is present. Or simply add it in the config and let the tpiu driver to verify it is there (not sure current driver does it already)

20:37 <zapb_> borneoa_, simply adding it to the config would throw an error or warning if not present, right?

20:40 <borneoa_> zapb_: with current code I'm not sure. But driver can be improved to run the check. The problem is that there are several implementations of tpiu, we need to cover them all. We need to find a common pattern to identify if tpiu is present

20:41 <zapb_> borneoa_, I agree, tpiu seems quite complicated at the moment, maybe even buggy (have to verify again). took me quite a while to get it running

20:42 <zapb_> borneoa_, are you working on tpiu "at the moment" ?

20:57 <borneoa_> zapb_: no, long time I didn't used it

20:58 <zapb_> borneoa_, okay, good to know. Maybe I find some time to work on it

20:59 <borneoa_> zapb_: in the first comment of the code are listed the documents I have used. I can try to reopen them to look for the common pattern

21:00 <zapb_> borneoa_, would be nice

21:03 <zapb_> borneoa_, btw, there is a fix for a segfault bug on gerrit

21:03 <zapb_> would be nice to have it merged soon

21:04 <zapb_> segfault on 'tpui create'

21:05 <borneoa_> zapb_: just reviewed. Minor typo in commit msg

21:24 <zapb_> borneoa_, thanks

22:12 <borneoa_> zapb_: just sent you a summary by email. We can check ARM_CS_C9_DEVTYPE.

22:26 <zapb_> borneoa_, thanks!