09:10 <gamiee> Hello everyone. I want to ask, how does debugging works, when there are two CPUs in the chain? Does OpenOCD exposes two GDB ports, or how is this done?

09:56 <PaulFertser> gamiee: two GDB ports, yes

09:57 <PaulFertser> Unless you are working with SMP cores where you declare them as such.h

09:57 <gamiee> PaulFertser: Sweet, that's great! And yeah, for SMP I would expect to treat it as "one system", but in this case, it's two fully separate cores. Thanks :)

09:58 <PaulFertser> Still single Telnet port and there you switch the current target with "targets" command.

09:59 <PaulFertser> gamiee: you can enable and disable taps dynamically from Tcl but you have to at least declare _all of them_ in advance.

10:00 <PaulFertser> (to handle chain changes if hardware reset disconnects some taps from the chain :/ )

10:00 <gamiee> Yeah, one telnet is understandable and actually good that it's that way. I plan to declare all of them.

10:01 <gamiee> But wait, if some device disconnects, doesn't chain break, resulting in non working JTAG at all?

10:14 <PaulFertser> idk, i'd expect at least something somehow being present on the chain after reset deassertion

10:17 <gamiee> PaulFertser : but if the chip resets, and it disconnects the JTAG Transport as well, there is no FIFO present, thus breaking the chain ,so I expect it will stop working at all.

10:21 <PaulFertser> gamiee: but is there anything at all left on JTAG in that state?

10:51 <gamiee> PaulFertser : sorry, not sure what exactly do you mean.

10:53 <PaulFertser> gamiee: you say hardware reset changes something about pinmuxing of that chip which affects jtag chain as seen from the outside, right?

10:55 <gamiee> PaulFertser: Correct. Let me explain the situation. When chip reset, pinmux is of course reset as well, so CPU0 and CPU1 JTAG's are disconnected from "outside world". Problem is, that BootROM enables only CPU0's JTAG, leaving CPU1's JTAG pins floating, thus not doing the FIFO. So I presume chain is broken and it cannot work at all. (I have solution for this on software level, just wanted to confirm that when one CPU's JTAG is physically not connected, TDI-

10:55 <gamiee> TDO is not connected as well, so chain is broken)

10:58 <PaulFertser> gamiee: hm, that's weird, so after any reset there's no way to talk to the target at all anyhow until some special code running on the target configures the muxing?

11:01 <Haohmaru> which chip was this?

11:03 <PaulFertser> Not to be disclosed yet Haohmaru

11:03 <PaulFertser> We'll know when the time comes.

11:03 <Haohmaru> top-sikrit chip?

11:15 <gamiee> Haohmaru: BL808

11:15 <gamiee> For some reason, they expose both JTAGs separately, instead of daisy chaining it inside of the chip

11:15 <Haohmaru> oh that one, it's unobtainable still, right?

11:16 <Haohmaru> someone told me about it few years ago but i couldn't actually find chips for sale

11:49 <gamiee> Hoahmaru: theoretically it should be able to get it, but yeah, not easy.

11:56 <Haohmaru> seems $vendor is targetting those chips at wireless stuff, so it's probably not for me then

12:01 <gamiee> Haohmaru : wdym?

12:02 <Haohmaru> i mean, i should probably not look at this chip even if it was available, i just need fast single core for muchos floating point math

12:23 <gamiee> Haohmaru: what about BL616?

12:29 <Haohmaru> that's less MHz

12:41 <PaulFertser> gamiee: so what's connected to JTAG rigt after reset on that BL808?

12:45 <gamiee> PaulFertser: Nothing, until BootROM setups CPU0 JTAG. (CPU1 JTAG needs manual configuration in firmware, or my workaround)

12:46 <PaulFertser> gamiee: and then after BootROM does you have that TAP in the chain working?

12:49 <gamiee> Haohmaru: 320MHz is quite fast. And I heard there is possibility to overclock to 480MHz as far as I remember.

12:49 <gamiee> PaulFertser: yes

12:53 <PaulFertser> gamiee: so probably you can manipulace CPU0 with Tcl to have CPU1 started and connected?

12:54 <gamiee> PaulFertser : yes, but I found another method. In BootROM, I will use some of their "hot-start" functionality to automatically execute enable of CPU0 and CPU1 JTAG, making both JTAGs working. This ways, chip still stays in BootROM and JTAG is enabled fast.

12:55 <Haohmaru> i don't know, generally i don't want to push an MCU over what the datasheet says, currently i've chosen STM32H723 which is 480MHz cortex-M7F

12:56 <PaulFertser> gamiee: so they did think about it, cool.

12:56 <gamiee> PaulFertser : they did not. This is just my workaround, "abusing" their BootROM functionality to do this. I use this functionality in BL602/BL702 to stay in BootROM after reset, if JTAG adapter is too slow.