11:19 <karlp> ok, time to bite the bullet and bisect

11:23 <olerem> ElReino: hi, what is CPU32 BDM?

11:26 <karlp> sounds like motorola stuff.

11:26 <karlp> BDM is the name for coldfire and probably 68k debug module

11:28 <ElReino> Yeah, it's SPI-like debug protocol for Motorola cpu:s

11:28 <ElReino> *CPUs

11:29 <karlp> feck, bisected 0.11 to master and got all passes.

11:29 <karlp> turns out this only fails when the cpu has been power cycled

11:29 <Haohmaru> is that quadsecting? ;P~

11:32 <olerem> ElReino: OpenOCD is working with JTAG/SWD chains and TAPs. If there is no such chain, it would be hard to implement. In current state, I can imagine some sort of code adapter to tell the maininfrastrucuture, that SPI is kind of local TAP.

11:35 <olerem> ElReino: with other words, I doubt some one is working on it, and you will need to spend some time to implement it.

11:50 <ElReino> olerem: Thanks for comprehensive answer, I might take a look at implementing it as there's no modern implementation of it for linux AFAIK

12:02 <olerem> ElReino: can you please answer one question, if it is not a secret: why?

12:19 <ElReino> olerem: It's because I want to reprogram a Trionic ECU, and all the tools are either only for Windows or DOS

12:21 <Fleck> dosbox then :D

12:24 <ElReino> That seems to be the easiest solution at this point

12:25 <ElReino> Although GDB debugging would have been great

12:29 <karlp> borneoa_: "armv7m_trace: get rid of the old tpiu code" definitively breaks trace for me :|

12:29 <karlp> this is painful, newer openocds would work if the target hadn't been power cycled before, so it appeared to be still work.

13:02 <borneoa_> karlp: what's the target? Is its script upstream?

13:03 <karlp> stm32wb55

13:03 <karlp> stock master.

13:04 <karlp> it's not really revertable to test nicely though.

13:09 <karlp> >>> mon itm port 0 on

13:09 <karlp> timeout waiting for ITM_TCR_BUSY_BIT

13:09 <karlp> that's certainly not helping much.

13:16 <karlp> just tested on an f3 as well, same behaviour.

13:17 <karlp> doesn't matter whether I use new style or old style config commands either.

13:21 <karlp> there's nothign obviously worng in the ITM config blocks, I've no idea whether it's stlink end or target config end.

13:36 <Haohmaru> was that the mechanism to print stuff over SWD (without having to use an actual UART) ?

13:36 <Haohmaru> this ITM thing

13:39 <karlp> it's one more pin actually, SWO.

13:39 <Haohmaru> ah, right.. so that suddenly stopped working?

13:39 <karlp> if you want to do it in band just over swd itself you need to use something like RTT or semihosting.

13:39 <karlp> well, because of changes in oocd it stopped working for my configs, yes.

13:40 <Haohmaru> hm..

13:40 <karlp> presumably other configs that borneo and that nxp guy are using must be working, because they needed those changes made :)

13:42 <Haohmaru> could it be maybe disabled.. the peripheral, iirc i remember reading some tricky stuff around the "debug unit" on my cortex chip

13:43 <karlp> it seems to be enabled, the ITM->TCR is valid, and same as in working case, just a BUSY bit set.

13:44 <Haohmaru> it's called "DSU" device service unit, actually.. i'm guessing that's an ARM thing and should be present and "the same" for all $vendors' chips

13:46 <Haohmaru> The Debug Communication Channels (DCCO and DCC1) consist of a pair of registers with associated handshake

13:46 <Haohmaru> logic, accessible by both CPU and debugger even if the device is protected by the NVMCTRL security bit. ...

13:46 <Haohmaru> "The DCC0 and DCC1 registers are accessible when the Protected state is active. When the device is protected, however, it is not possible to connect a debugger while the CPU is running (STATUSA.CRSTEXT is not writable and the CPU is held under Reset)."

13:46 <Haohmaru> sorry, that whole thing should have been quoted..

13:47 <Haohmaru> but now i think this looks kinda atmel-ish so it's probably not very arm-ish

14:14 <borneoa_> karlp: downloaded the doc of wb55. It's dual core, but only first core has its and tpiu at usual addresses. Should work fine. I only have an F4 here. Let me try again

14:19 <karlp> well, f3 is also busted, and that's a pretty plain one.

14:20 <karlp> I'm about out of time for the day though unfortunately.

14:20 <karlp> and wb55 works jus fine before that commit

14:25 <borneoa_> Just tested f4 and works. Can you send me the list of commands you have run to get the error? Maybe we are not using it in the same way

14:27 <Haohmaru> could it be his debugger malfunctioning or damaged?

14:38 <karlp> just https://github.com/karlp/l2-simple/blob/main/openocd.cfg#L8

14:38 <karlp> add a 2000000 afterwards or not depending on where in history you are...

14:38 <karlp> Haohmaru: no, works with older openocd, has worked with openocd for years

14:39 <Haohmaru> ah

17:19 <borneoa_> karlp: sent out 2 patches. The first is a real fix, the other just prevents a dummy message

17:33 <karlp> it wasn't working for me with the new command style either iirc, was that because it was before the implicit init at end of config file?

17:33 <karlp> and I'd need to add an explicit init to my files before that line?

17:33 <karlp> will test the patches later, not sure if it will be tonight though I'm afraid, definitely no later than monday morning :)

19:35 <karlp> borneoa_: that works thanks :)

19:36 <karlp> but I went and restested again, and it is broken with new command as well as old.

19:53 <borneoa_> karlp: what this patch fix is the old event handler incorrectly executed before 'init'.

19:54 <borneoa_> karlp: can you please elaborate what is broken? What's the error or the incorrect outcome?

19:56 <borneoa_> karlp: I'm using a nucleo board wb55 with the config you pointed. Only added the pin speed to the command

19:59 <karlp> no trace output

19:59 <karlp> with that path I get trace output again.