<p><span class="h-card" translate="no"><a href="https://ioc.exchange/@azonenberg" class="u-url mention">@<span>azonenberg</span></a></span> I can absolutely ask her but I&#39;m like... trying to have fun here</p>

<p><span class="h-card" translate="no"><a href="https://ioc.exchange/@azonenberg" class="u-url mention">@<span>azonenberg</span></a></span> I think I&#39;ll work on probe-rs integration for Glasgow for modern chips, which won&#39;t be very fast but will cover all of the bizarre complexity of ADIv6 without blocking it on me implementing it</p><p>once that&#39;s done I&#39;ll start looking at Glasgow-native acceleration for it that should give you 1-2 OOM more speed, at the cost of perhaps less compatibility</p>

<p><span class="h-card" translate="no"><a href="https://mastodon.social/@whitequark" class="u-url mention">@<span>whitequark</span></a></span> Ah ok that explains it. No chance of getting help from your scarily productive headmate?</p>

<p><span class="h-card" translate="no"><a href="https://ioc.exchange/@azonenberg" class="u-url mention">@<span>azonenberg</span></a></span> the reason it&#39;s needed is because you can&#39;t debug a core when it&#39;s in deep power down and you may still need to debug its sibling core</p><p>previously you&#39;d have all sorts of debugger &quot;chicken&quot; bits for power-saving modes but that makes it really hard to figure out where all the power goes</p><p>this was solved by the cores having independent debug ports</p>

<p><span class="h-card" translate="no"><a href="https://mastodon.social/@whitequark" class="u-url mention">@<span>whitequark</span></a></span> Interesting.</p><p>The most complex JTAG topology I recall seeing was XC7Z with an ADIv5 TAP and a boundary scan TAP (IIRC the FPGA program/debug TAP was also the boundary scan TAP).</p><p>But there was an option to split the two via EMIO and have separate TAPs for the FPGA and ARM using FPGA GPIOs to debug the ARM, which I actually tried once.</p>

<p><span class="h-card" translate="no"><a href="https://ioc.exchange/@azonenberg" class="u-url mention">@<span>azonenberg</span></a></span> Glasgow is my project</p>

<p><span class="h-card" translate="no"><a href="https://mastodon.social/@whitequark" class="u-url mention">@<span>whitequark</span></a></span> (also just one girl? I thought you were plural :P)</p>

<p><span class="h-card" translate="no"><a href="https://ioc.exchange/@azonenberg" class="u-url mention">@<span>azonenberg</span></a></span> multidrop SWD is basically a requirement for some modern low-power RF SoCs from Nordic and stuff, it&#39;s kind of a big deal actually</p>

<p><span class="h-card" translate="no"><a href="https://mastodon.social/@whitequark" class="u-url mention">@<span>whitequark</span></a></span> Multidrop SWD????</p><p>Honestly I find even multidrop JTAG is very rarely used. The most I see is like a boundary scan TAP and a programming/debug TAP on a single physical chip, but multiple packages in one scan chain are not common.</p><p>Vendor tooling being the main reason. I made a STM32 + Artix-7 board once and found it was near impossible to debug the system because I had to keep jumping between Vivado and OpenOCD and couldn&#39;t use both simultaneously to look at ILA and firmware view of the system.</p><p>And that&#39;s even before you get into voltage level compatibility issues.</p>