<Haohmaru>
so, don't keep your secrets inside the MCU
<Haohmaru>
the GD32H7xx still aren't available anywhere
<Haohmaru>
i was almost gonna choose one of those for my audio board, what stopped me was that i had no clue about the price, thus i went for STM32H723
<Haohmaru>
well, possibly a few other reasons too
<Haohmaru>
but 600MHz looks tasty
<Haohmaru>
and the datasheet had some noob-friendly parts which i appreciate a lot
<Haohmaru>
so the daplink firmware seems to be using RTOS, how unfortunate
<Haohmaru>
i wonder if i would manage to "steal" just the code that sits above it and sandwich it between my "spi3swd" and main()
<Haohmaru>
but my nose says "probably not"
<Haohmaru>
the alternative is to RTFM everything about USB and write my own from scratch, then RTFM about the communication between the daplink and the PC x_x
<clever>
i mostly just read the openocd source, and brute-forced things until it worked
<Haohmaru>
examples are welcome, but i'm trying to make SWD
<clever>
the bulk of the protocol will be similar
<Haohmaru>
i know nothing about USB, all i know is that i should be looking at "bulk", because the current "cheap" daplink debuggers i have are not using that and thus things are kinda slow
<clever>
one of these says that it supports jtag mode, and you would change it to swd
<Haohmaru>
i mean, they have 12Mbit USB, same as the chip i'm using, but i was told that even on that, when using "bulk" the communication will be faster
<clever>
usb has ~4 main types of transfers, control, interrupt, bulk, and isochronus
<clever>
i think cmsisdap doesnt use control
<clever>
bulk can move large packets in both directions
<Haohmaru>
yeah, afaik the cheap daplinks do things in some slow-ish way, and there is a faster way to do it, afaik openocd already supports it, thus it's up to the daplink to also do it (but the cheap ones don't)
<clever>
interrupt is meant for things like a mouse/keyboard, where your waiting for some event
<clever>
isochronus is for constant rate stuff, like audio or video
<PaulFertser>
Guess control is used to read the USB descriptor no?
<clever>
yeah, control reads the descriptors and sets a lot of stuff up
<Haohmaru>
unfortunately i also want to have the optional USB-UART in my daplink, thus afaiu, my USB will have to be like a "composite" device or something like that, which makes things more difficult
<PaulFertser>
And then the old CMSIS-DAP/DAPLink is using HID over Int, while newer is using bulk iirc.
<clever>
Haohmaru: the example i linked is exactly that
<Haohmaru>
HID was for USB devices like mice/keyboards, right?
<PaulFertser>
Still is :)
<clever>
ive programmed a pico to show up as 2 usb serial ports and a CMSISDAP adapter
<Haohmaru>
okay, i'll have to stare at it
<clever>
one serial port gets forwareded to the hw uart, complete with baud rate control
<PaulFertser>
Some people liked it because that's the only thing available to Windows userspace without additional kernel drivers.
<clever>
the second serial is for printf from the pico itself
<Haohmaru>
i honestly don't care about M$OS for this debugger
<clever>
just act like M$ doesnt exist :P
<Haohmaru>
clever, what chip is this on?
<clever>
Haohmaru: rp2040
<Haohmaru>
oh
<clever>
but anything that supports tinyusb should work similarly
<Haohmaru>
i'm on samd21
<Haohmaru>
and i made a 3x SPI monster circuit to do the SWD signals
<Haohmaru>
in theory up to 24MHz
defiant has joined #openocd
ALTracer has joined #openocd
<ALTracer>
zapb__: Three weeks later I've got around to it. PR8667+8668 kinda works with the ubiquitous WeActStudio.BlackPill AT32F403ACGU7 with FT4232H JTAG at 400 kHz.
<ALTracer>
I had to patch the thousand line array to add first 512 KiB bank of flash, because there's no dualbank support whatsoever for now, and register 0x70050347 PID.
<ALTracer>
Also OpenOCD has the same problem of JTAG-DP intermittently dead which breaks erase/write (target left erased) at 500 kHz and faster (100-400k work)
<ALTracer>
I don't have an SWD resistor hack on this module, but it's a thing worth trying
<ALTracer>
I would also ask to register AT32F437ZMT7 as found on AT-START-F437, so that I could test it (I'll patch locally for now), or even register all first banks, be it 2048 KiB or whatever, that's still plenty for some programs.
<ALTracer>
A nice-to-have is to complain which PID and device_series had failed all LUT matches in artery_probe(), but I don't have a strong opinion on it in this project.
<PaulFertser>
ALTracer: do you have just a bare board and connect signals from FT4232H directly to target's SWD?
<PaulFertser>
And you just short TDO and TDI together?
<ALTracer>
It's one of those chinese simple boards, I haven't made a cable with 330-470 ohm resistor between TDI/TDO yet, but I can, later
ALTracer has quit [Read error: Connection reset by peer]
ALTracer has joined #openocd
<PaulFertser>
ALTracer: my point is that you also need _series_ termination on all signal lines usually.
<ALTracer>
At 30 MHz yes
<PaulFertser>
ALTracer: 47 Ohm or 100 Ohm would be fine. And it's needed because you essentially connect a strong push-pull MOS output to a high-Z input. That means that without termination you're likely to get ringing.
<PaulFertser>
_on every edge_
Guest59 has joined #openocd
<PaulFertser>
So it doesn't matter that much what frequency you try to run on, the ringing if not suppressed can be affecting operation even at 1 MHz.
<ALTracer>
I saw ringing on DSO at high slew rates on other devices, but it does not ruin signal integrity
<ALTracer>
SRST pulls TRST is the problem
<PaulFertser>
But FT4232H does have a high slew rate.
<ALTracer>
Doesn't your backend control it depending on adapter speed?
<PaulFertser>
I'm afraid it doesn't, rigt.
<PaulFertser>
I do not even know if it's possible to configure on FT4232H at all.
<PaulFertser>
Usual way is to have a high-speed buffer to provide voltage conversion connected to the FTDI chip and then to have source series termination resistors on all data lines.
<ALTracer>
It may not have STM32 OSPEED alike registers or commands indeed.
<ALTracer>
Steppenprobe is a nice design which implements buffers, serial termination, and SWD/JTAG switch. I don't have one.
<PaulFertser>
If you have an oscilloscope handy please do check the signal integrity, it's known to cause problems depending on target and other factors. Even at slow speeds because of high drive strength on every edge.
<PaulFertser>
The resistor hack however should be irrelevant when you connect directly to FTDI chip because current OpenOCD switches TDO to input when appropriate so it doesn't interfere.
<ALTracer>
I moved TMS wire from ADBUS3 to 2 and shorted it with ADBUS1, this worked both with OpenOCD and BMDA.
<PaulFertser>
ALTracer: btw, please do not forget to add your review to Gerrit so it's not forgotten/lost.
<ALTracer>
Do I need to register?
<PaulFertser>
In a way but you can use your own OpenID instance. Or you can use Github OAuth or some other OAuth providers.
<ALTracer>
GH works
<PaulFertser>
Cool
<ALTracer>
SWD adapter speed 1500 is highest working in direct wire setup, 11 KB/sec load achieved
<PaulFertser>
Would be interesting to learn if series resistors improve the situation or not. They might I think. The SWD hack resistor is unlikely to change anything.
<ALTracer>
They would improve Black Magic Probe Firmware on STM32F411CE signal integrity situation, where I chose to control SWCLK OSPEED at 8.7 MHz, but that's another board with no expectations of surrounding wires
<ALTracer>
I'll try to ask my PCB engineers to manifest some shim with serial terminations and jumpers for JTAG/SWD on this four-channel HS beast. We mostly use it for 4x UART at 6 Mbaud (it also does 8M, 10M, 12M) but 16ms idle timers are terrible with 2kB FIFOs.
<ALTracer>
I also have a JLink V9, STLink/V2, some random Pico/*Pills and maybe CMSIS-DAP runs on them
<PaulFertser>
Nice
<Haohmaru>
so many debuggers, you must be free of bugs!
<ALTracer>
When AIRCR SYSRESET request is written to JTAG-DP and then AT32F403A responds with its IDCODE of 0x4BA00477, does it mean SRST pulls TRST or gates JTAG?
<ALTracer>
neither of options helped
Guest59 has quit [Quit: Client closed]
ALTracer has quit [Read error: Connection reset by peer]
Hawk777 has joined #openocd
ALTracer has joined #openocd
Haohmaru has quit [Quit: saionara]
<PaulFertser>
ALTracer: that IDCODE looks completely normal for Cortex-M and if you get it it means at that moment you're reading TRST is _not_ asserted.
<PaulFertser>
ALTracer: I can clarify the meaning of the options. SRST gates JTAG means that when SRST is asserted (pulled low) you can not have any JTAG communication with the target at all.
<PaulFertser>
ALTracer: SRST pulls TRST means that for whatever silly odd reason when you assert SRST also somehow the _JTAG state machine_ gets reset, as if you asserted TRST.
<ALTracer>
With BMDA when I hold SRST button it still scans JTAG up to cortexm
<ALTracer>
But when I (gdb) load, it wants to write AIRCR sysreset, or read from DEMCR, and that results in a bogus transaction of DP read IDcode, not AP read mapped AHB-AP
<ALTracer>
So I'm inclined to think Arterytek failed to decouple TRST from SRST
<ALTracer>
of course I can't observe which state JTAG TAP SM is in
<ALTracer>
PB4 itself is free and has a weak pullup, I wasn't using that
<PaulFertser>
TRST is only about the JTAG state machine, it's normally unrelated to debug logic.
<PaulFertser>
If the target is proper then OpenOCD should be able to do "reset_config connect_assert_srst" (it's deasserting SRST at the right moment to let it halt.
<PaulFertser>
With OpenOCD if you tell OpenOCD that you have SRST connected then it's never using sysresetreq.
<ALTracer>
I did `mon reset_config srst_only srst_pulls_trst srst_gates_jtag`, that didn't help
<PaulFertser>
Didn't help with "load" ?
<PaulFertser>
By default load first does "reset init", then flashes, then "reset halt". Which part failed?
<PaulFertser>
I think srst_pulls_trst can be harmful if it's not actually true and you're using JTAG and SRST is not resetting the state machine. I think if you can read IDCODE with SRST asserted then it certainly means SRST does NOT pull TRST.
<ALTracer>
Neither helped, neither defaults nor srst_only
<PaulFertser>
Helped what?
<ALTracer>
This chip has some problem which I'm not qualified enough to diagnose and understand myself
<PaulFertser>
srst_only means you only connected SRST to the target and TRST shouldn't be used.
<ALTracer>
I can record logs using PR8667 code at -d3 verbosity and pastebin
<ALTracer>
Reset init should've failed, I think
<ALTracer>
The mentioned event is fatal for BMDA, but OpenOCD just keeps hammering on and I can't catch it
<PaulFertser>
"reset init" is essentially "reset halt", then running the reset-init Tcl handler if present.
<PaulFertser>
So for any new target getting "reset halt" working is essential, that comes before flash drivers etc.
<ALTracer>
Everything works in SWD transport
<ALTracer>
It's a normal SWJ-DP and CM4F, no CoreSight stuff, no complicated infra. ETM might be missing, but CM3-TPIU works at least for SWO.
<ALTracer>
Why would selected IR (and IRlen) change from APACC 35 to IDCODE 32?
<ALTracer>
I can also try using UrJTAG for a low-level manual mode with a suitable adapter
<PaulFertser>
Hm, are you sure "reset halt" works nicely with SWD but fails with JTAG on the same target? With hardware SRST connected and enabled (srst_only)?
<ALTracer>
That's how it works in BMDA, I haven't paid attention to OOCD
<ALTracer>
especially having to juggle minimodule-swd.cfg
<ALTracer>
and changing pinouts of FT4232H
<ALTracer>
SWD 0b111 is no-ack and both gdbservers perform retry transaction per protocol
<ALTracer>
JTAG 0xffffffff:0x3 is invalid
<PaulFertser>
Well, blackmagic code differs so it doesn't directly translate to OpenOCD experience.
<ALTracer>
If you give me an exact list of human instructions or a Tcl script and wiring, then I'll run it and pastebin the precise results
<ALTracer>
well I don't have a FTDI MPSSE at home, but I'll see what I can do with a e.g. CMSIS-DAP
<PaulFertser>
Yeah, any adapter should behave about the same.
<ALTracer>
Of course I have been mainly using OpenOCD since 2018, but switched to BMD in 2023 because that codebase was so much easier to add support to of Gigadevices GD32E508 and Arterytek AT32F437
<ALTracer>
and I was given a project to port onto these
<PaulFertser>
Hm, that's surprising. Support for flash driver specifically was easier with Blackmagic?
<PaulFertser>
I wrote and fixed some OpenOCD flash drivers, it was "ok" experience, somewhat enjoyable even.
<ALTracer>
No, flash driver was just stm32f1.c because that's compatible, I had to add probe/detect hooks, and Gerrit 6794 was frozen
<PaulFertser>
Frozen?
<ALTracer>
PaulFertser: afterwards I did decide to author at32f43x.c because its FPEC was at a different base address and dual-bank split didn't match 2x512 KiB. So I have some knowledge of how AT32F4 works by quacking as STM32F1. It has nothing in common with STM32F4.
<PaulFertser>
Yes but what do you mean by was frozen?
<ALTracer>
When I saw it in 2023 as no activity since December 2021, (it sits like this even now), I didn't get any hopes about getting it in nearest release or bleeding edge git
<ALTracer>
Also it's missing the 0x790007a3 bscan tap and JTAG tap value is wrong.
<ALTracer>
Sorry, I digress
<PaulFertser>
ALTracer: if there're no unresolved review comments and you have hardware to test you can just rebase on top of current master, re-test and send an updated version.
<PaulFertser>
And ping maintainers every now and then.
<ALTracer>
I have had a single GD32E508ZE since then, but I have never contributed to OpenOCD gerrit proper.
<PaulFertser>
Gerrit is relatively comfortable to use. If the original author is not active there's no problem with you or anybody else pushing updated versions.
<ALTracer>
Maxgerhardt is still active on GH though
<PaulFertser>
Well, not active in pushing OpenOCD change upstream.
<PaulFertser>
It's ok to took over someone else's work and continue the effort.
<ALTracer>
That's generally true, however:
<PaulFertser>
Unfortunately OpenOCD project is really low on work force so basically the contributors need to be kinda pushing, reminding about their patches regularly.
<ALTracer>
Does this project have geo restrictions or no-contributions policy for certain countries?
<PaulFertser>
No
<ALTracer>
I wouldn't want to attract unwanted attention
<PaulFertser>
You do not need to specify what country you're from or what business you work for or anything like that.
<PaulFertser>
Adding support specifically for something that's obviously russian military chips (and not obtainable and not suitable for civilian purposes) might get problematic, true. But other than that it should be fine.
<ALTracer>
In that case I might try, next week is as good as any
<ALTracer>
Niiet pushed something, Milandr carries its own fork
<ALTracer>
None of their chips reached my team in any actionable capacity, so I'm not bothered.
<PaulFertser>
I wrote the flash driver for milandr plastic stm32f1-alike chip back then, it was super-fast flashing compared to stm32f1. I wonder why they have their own fork instead of contributing upstream now. But probably it makes sense if they do not sell to individuals anymore, idk.
<ALTracer>
mdr32f92qi? I ported NuttX onto mdr32f1qi to leverage its internal Ethernet 100 PHY, but never completed to that stage because it's flash-constrained
<PaulFertser>
Yes, iirc it was the name.
<ALTracer>
PaulFertser: for 3.5h ago cmdline, `init; reset init` fails, I posted -d3 and tail of -d4
<ALTracer>
Using koendv/free-dap on stm32f411ce blackpill, wiped first 16 KiB which otherwise contained BMD bootloader (BMD firmware is offset), I may have patched the pin mappings but it provides JTAG+SWD via HID.
<ALTracer>
0x07 in, 0x6974008e in is telling, OpenOCD expects TAP to remain in DR scan, but it got reset and keeps spewing IDCODE (from default IR)
<ALTracer>
reset_config none: works (if nobody unmaps SWJ-DP)