<clever>
PaulFertser: pivoting to the other side of the solution, is src/jtag/drivers/cmsis_dap_usb_bulk.c the one i want to read for implementing a usb jtag adapter?
<clever>
Info : 34 12 cmsis_dap_usb_bulk.c:339 cmsis_dap_usb_open(): Using CMSIS-DAPv2 interface with VID:PID=0x2e8a:0x0009, serial=E6605838839D652F
<clever>
ok, thats progress
<clever>
but now i'm having trouble getting that first bulk-out to actually show up at the device end
<clever>
ah, the CDC uart doesnt seem to work within the usb callbacks
<clever>
yep, now i get logs
<clever>
Info : 37 38 cmsis_dap.c:1151 cmsis_dap_get_version_info(): CMSIS-DAP: FW Version = wifi-jtag (usb mode)
<clever>
yep, slowly working thru support for each command it sends
nerozero has joined #openocd
JakeSays_ has joined #openocd
JakeSays has quit [Ping timeout: 265 seconds]
Hawk777 has joined #openocd
renrelkha has quit [Read error: Connection reset by peer]
renrelkha has joined #openocd
JakeSays has joined #openocd
JakeSays_ has quit [Ping timeout: 245 seconds]
Haohmaru has joined #openocd
Hawk777 has quit [Quit: Leaving.]
slobodan has joined #openocd
slobodan has quit [Remote host closed the connection]
defiant has joined #openocd
defiant has quit [Quit: defiant]
Guest18 has joined #openocd
Guest18 has quit [Ping timeout: 256 seconds]
<PaulFertser>
zapb_: https://termbin.com/fftb0 seems to be needed to cross-build for windows when libjim 0.83 is an external library.
<zapb_>
PaulFertser, only on windows?
<PaulFertser>
zapb_: I only tested windows cross-building and native building on GNU/Linux. That include stdio.h fixed windows and didn't harm GNU/Linux.
<PaulFertser>
I run distro packages for amd64,armhf,i386 builds and self-compile dependencies for both windows builds. So versions are different. I used your 0.4.0 libjaylink and 0.83 jimtcl for windows (latest tagged releases).
<borneoa___>
Freebsd 13 has libjim package
<PaulFertser>
borneoa___: I was preparing the build machine to stop requiring submodules today, that's the context.
<clever>
PaulFertser: you able to help debug some openocd stuff?
<PaulFertser>
clever: probably but my knowledge of the Arm debug protocol is far from being deep.
<clever>
and a target file for this already exists in openocd master
<borneoa___>
Homebrew for MacOS has no libjim!
<clever>
then down at line 602, it began trying to access the debug port
<clever>
and at 634, it reported an invalid ack
<borneoa___>
I have no experience with MacOS, no idea if there are alternative repos to homebrew
<clever>
borneoa___: nix is also an option, it runs on darwin
<borneoa___>
clever: thanks, I'm checking...
<PaulFertser>
borneoa___: can be added to Homebrew itself, it's not hard to contribute there
<PaulFertser>
clever: yes, something went wrong there, it sent a queue of several operations it needs to examine the target and failed to get the right response.
<clever>
ok, so the second scan, after the failure, is a read of CTRL/STAT
<clever>
it first shifted a 0 into the register during a read, which should be ignored, and got 80000000 back
<zapb_>
borneoa___, they have one OpenOCD release cycle to add it -> at least one year ;)
<zapb_>
PaulFertser, thanks, I will test it and push a patch that fixes this issue
<clever>
then it hit up RDBUFF, which makes sense
<clever>
the resulting 32bit value it got, was f0000000, which makes sense, ive seen the same thing, the power up req/ack
<clever>
but it also got a 7 in the wait/ack area
<clever>
> All other ACK encodings are reserved.
<clever>
only 1 and 2 are valid, 7 is invalid
<clever>
but i think i see why
<PaulFertser>
zapb_: thank you!
<clever>
i'm not clearing the usb buffer fully, and i'm only setting bits when TDO is high
<clever>
so sometimes, bits from a previous packet leak thru
<clever>
PaulFertser: that looks like progress, its spewing debug non-stop and has yet to exit
<clever>
i think thats normal, due to openocd having to poll for things?
<clever>
this seems to work, and gives the best flexibility
<clever>
but so far, only one pi is responding, even with my old IDCODE scan stuff
<clever>
i should probably sleep now, its 10am, lol
joconor has quit [Ping timeout: 265 seconds]
joconor has joined #openocd
<zapb_>
PaulFertser, do you use a jimtcl package with for mingw64 or did you compile it from source?
<Haohmaru>
clever, noooo, that's exactly what the monsters under the bed are waiting for
Haohmaru has quit [Quit: saionara]
nerozero has quit [Ping timeout: 264 seconds]
<PaulFertser>
zapb_: compiling it from source
<PaulFertser>
zapb_: "configure --build=x86_64-unknown-linux-gnu --host=i686-w64-mingw32 --with-jim-shared --with-ext=json --minimal --disable-ssl --prefix=/usr --enable-shared" then I "make install DESTDIR=/opt/win32" and then I recopy the DLL because jimtcl has a bug and replaces it with an invalid symlink (libjim.dll -> libjim.dll).
Hawk777 has joined #openocd
cozycactus has joined #openocd
<zapb_>
PaulFertser, I see no build issue on Windows with mingw64?
<zapb_>
(compiled from source, jimtcl 0.82)
slobodan has joined #openocd
slobodan has quit [Remote host closed the connection]
slobodan has joined #openocd
<zapb_>
PaulFertser, okay, the issue is "introduced" in libjim >= 0.83
<zapb_>
borneoa___, the missing #include <stdio.h> sounds familiar to me, did we discuss this issue before?
zjason`` has quit [Read error: Connection reset by peer]
zjason`` has joined #openocd
<clever>
PaulFertser: ive confirmed that this CMSIS-DAP driver works on 4 of the attached pi's, a pi2, pi3b, pi4, pi0w, and pi3a
<clever>
it even nicely recovers from a target boot-looping due to low voltage, lol
<clever>
exactly the same as it did with the old bcm2835 gpio bitbang driver
<PaulFertser>
zapb_: yeah, I mentioned I hit the issue with 0.83 specifically as that's the last tag they have.
<PaulFertser>
Have you found issues with the way I suggested to patch it? Seems logical.
<PaulFertser>
clever: nice progress! Yes, OpenOCD tries to not duplicate functionality so all the drivers should be equal when at all possible.
<clever>
only 2 pi's are unresponsive, there is a pi4 that doesnt even work over ssh, and one board appears to have 2 bad solder joints
<clever>
i switched the pico into gpio mode, and wiggled each pin by hand(over the uart), and 2 dont show up on the far side
<clever>
so that just leaves one issue, i have 6 debug adapters, 6 targets, and the openocd configs want to use the same ports
<PaulFertser>
clever: you have to specify different ports explicitly then, with gdb_port and the other commands.
<clever>
yep
<PaulFertser>
For multi-core non-SMP configs OpenOCD will listen for more than one gdb port, the next core gets port + 1.
<clever>
but how would that interact with the stock ah
<clever>
so if i just set a different starting port for each, it will auto-increment
<PaulFertser>
zapb_: I can downgrade to 0.82 for the windows builds if you think that's useful, no problem but guess it's not much hassle to fix compatibility with 0.83 now too?
<PaulFertser>
zapb_: I see it was remove from jim.h in 0.82-28-g41f431f and apparently for a good cause.
slobodan has quit [Read error: Connection reset by peer]
slobodan has joined #openocd
<borneoa___>
zapb_: the fix for Jim 0.83 should be already merged
<borneoa___>
zapb_: or there is another for windows build?
<clever>
PaulFertser: oh, one minor issue, i dont see any signs of CMSIS-DAP being ADI aware, so its not capable of repeating things when the WAIT flag is present on the debug port
<clever>
so in the event of a stall, commands will fail and openocd will need to retry them, harming speed
<PaulFertser>
borneoa___: I needed https://termbin.com/fftb0 to build, I didn't check if it was already offered or merged.
<PaulFertser>
clever: right but WAITs are not that often. OpenOCD uses the special batch mode with USB adapters which asks the target itself to ignore all the commands after the first that failed so just handling WAITs on the adapter without changing that assumption might be problematic.
<clever>
PaulFertser: yeah, that special "ignore all other" mode, means there is time (both on usb and jtag) that gets wasted
<borneoa___>
PaulFertser: Gerrit 8512, merged on October 5
<zapb_>
PaulFertser, fixed by rebasing
<clever>
if the CMSIS-DAP adapter knew it was in ADI mode, and was aware of the WAIT's, it could retry automatically, and it would be 100% transparent to openocd?
<zapb_>
borneoa___, yep, just noticed that there is already a patch
<clever>
it would just appear as if commands never stalled
<clever>
although, you would also need to tell the target to not latch up and fail future commands
slobodan has quit [Ping timeout: 255 seconds]
<PaulFertser>
borneoa___: thank you!
<PaulFertser>
clever: exactly what I was thinking about.
<PaulFertser>
clever: probably daplink/cmsis-dap reference implementation does just that in SWD mode? I can't clearly remember.
<PaulFertser>
clever: because JTAG is a more generic thing and cmsis-dap protocol treats it essentially as a long bitbanging sequence so one can use it for FPGAs and boundary scan and what's not. While SWD is specifically meant to transport ADI and so the USB API level is different there.
<clever>
i did also notice in the -d4 output, that openocd is sending the 35bit commands as a 3bit plus 32bit command
<clever>
as seperate sequences
<PaulFertser>
In separate BULK transactions?
<clever>
in the same bulk usually
<clever>
each bulk has multiple items
<clever>
however, it did also notice, the TMS stuff is rather in-efficient
<PaulFertser>
I see. Not sure why that is so. I remember touching that driver but that ways years ago.
<clever>
each clock of TMS, is a 1 byte side, and a 1 bit buffer, holding 1 bit to shift out
<PaulFertser>
Ten years :)
<clever>
also, the 32bit transfers, are done as 2 sequences as well, a 31bit transfer (1 byte size, 4 byte buffer holding 31 bits)
<clever>
then a 1bit transfer, with 1 byte of size, and 1 byte of buffer
<clever>
because TMS has to be set for the final clock of a 32bit transfer
<clever>
that 31+1 transfer is also what messed me up when writing the driver
<clever>
i returned the result packed into 4 bytes, when it should be 31bits in 4 bytes, then 1 bit in a byte all by itself
<PaulFertser>
ef02b69b14d133b061217a91add5a028a77e86bc 15x speed up, you can imagine how grossly inefficient it was before :)
<clever>
oh, i has 1ms sleeps, before and after TCK
<clever>
it was horid slow :P
<clever>
then i did the math, and realized that even with 1ns sleeps, its still pretty slow
<clever>
but 1ns is at least "fast" in terms of how quickly openocd reacts now
<clever>
i also had another thought...., CMSIS-DAP over udp??
<clever>
if i just pop open src/jtag/drivers/cmsis_dap.c and jam a udp driver into cmsis_dap_backends, it would almost fit
<clever>
so, some goals for the future, SWD support, ch32 support, and wifi support
a3f_ has joined #openocd
a3f has quit [Ping timeout: 252 seconds]
<PaulFertser>
What would be an advantage over TCP?
<PaulFertser>
That you would get start and end of the packet automatically?
<PaulFertser>
And with TCP you'd need to invent some framing, yes?
merethan has quit [Read error: Connection reset by peer]
merethan has joined #openocd
cozycactus has quit [Quit: Connection closed for inactivity]