-
Notifications
You must be signed in to change notification settings - Fork 125
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Possible lead on One Wire #2
Comments
Since writing that (yeah, like the same day or so) WCH finally broke down and provided doc for their protocol. Check it out at https://github.com/openwch/ch32v003/blob/main/RISC-V%20QingKeV2%20Microprocessor%20Debug%20Manual.pdf Closing. |
Note that their document is incomplete. It doesn't describe how to enter debug mode, or anything like that. I am toying with at some point writing an ESP32-S2 flasher tool. |
I haven't tried, but I think that's covered in 3.2.
All/most of this class of probe requires the processor be halted. Some
tools just halt and unhalt very quickly so you don't really realize that
it has been halted at all. THis is just how things like watchpoints
(without hardware support) work - starting and stopping debug mode a
zillion times.
It looks like this protocol would be pretty slow to bit-bang, even for
something like a BL702 or other 100+Mhz part. OTOH, it looks like it would
be a challenge to hit the timing requirements with a normal software
implementation. Something like the MPSEE
<https://atadiat.com/en/e-ftdi-mpsse-engine-programming-basics-a-gui-example/>
on FTDI family or the PIO Engine on RP2040
<https://www.digikey.com/en/maker/projects/raspberry-pi-pico-and-rp2040-cc-part-3-how-to-use-pio/>
that could be dedicated to hammering the bits and letting the bigger micro,
which is still on the other side of USB from the Real Computer for latency
reasons, handle to divide it all up and still have a reasonable performance.
What are you thinking of using to implement this first? Byte assembly is
going to be hard on a general purpose core that has USB.
As the twitter thread marchies along, suggestions have included PWM and
(sigh) counting clock cycles between toggles.
…On Wed, Feb 22, 2023 at 3:42 PM CNLohr ***@***.***> wrote:
Note that their document is incomplete. It doesn't describe how to enter
debug mode, or anything like that. I am toying with at some point writing
an ESP32-S2 flasher tool.
—
Reply to this email directly, view it on GitHub
<#2 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCSD36MWMZNRYAQEOCVMY3WY2B5RANCNFSM6AAAAAAVDHUHZ4>
.
You are receiving this because you modified the open/close state.Message
ID: ***@***.***>
|
I would recommend never using FTDI because of their history bricking products in post. But, you could probably do it in hardware on the RPI, though virtually all micros with USB shouldn't have any issue working with this in straight GPIO. Yes, you would have to disable interrupts while you're reading/writing individual bits, but it's only about 1/2 a microsecond. And it should work on any part that's ~12MHz or faster. For something like the ESP32-S2 this is really easy since you can disable interrupts for 30-40us without any impact to the overall system. Just writing to IO ports in C typically only takes 1 or 2 cycles as long as you don't use things like HALs. Just use #defines to turn pins on/off, as needed. It does preclude the full-sized raspberry pi GPIOs but it does mean everything like the following would be very well suited:
Charles |
I guess my overall suggestion is - why not just use GPIO with disable/enable interrupts? |
I guess I should also clarify - there are systems where writing to GPIO is 5-9 cycles, like the ESP or other high performance chips, but speaking in absolute time, that is either reliably many cycles, or, the jitter on the writes is well constrained. |
Also, bleh, sorry for my attitude just a bit of a rough day. |
TBC: I'm not arguing with you or begging you to proceed. I just saw a document that looked helpful to one of your notes and later that day, the spec became more open so I shared that, too, and tried to help volley around some ideas to help move along one of your scratch files on Github that I can't find right now. I have no skin in this game. So apologies if I've stressed you out. Please rest well. :-) I mentioned RP2040 over Pi3/Pi4's general purpose SoCs because it has two tiny little PIO engines hanging off the the main ARM core(s) that specialize in bit-twiddling like this. See, e.g. https://learn.adafruit.com/intro-to-rp2040-pio-with-circuitpython?view=all - you could have all of the bit-banging running on that and much of the JTAGgy state-machines running in the ARM cores and servicing USB packets to get the work done. The MPSEE on the FTDI parts has similar, but lesser known, features. (I understand and agree with your disgust with them.) MPSEE's what allows it to do SDLC and JTAG and and other weird stuff. And, yes, I'd already done the rough napkin math and even a "normal" little MCU like an STM32F103 or GD32VF103 108Mhz or even a BL702 from Sipeeed's $4 debugger pod at 144Mhz sitting in poll loops with interrupts disabled would possible, but still not exactly leisurely to hit all the targets. I also haven't studied what happens if you under and DON'T hit all the targets. Underruns and retries aren't awesome, but we're debugging a $.10 part so our standards should be pretty low. Simply having a 144Mhz clock instead of a 25Mhz is a big advantage, of course, but a little 2-cylinder bit-banger hanging off the edge just dedicated to hand-holding this thing might not be terrible. I'm perfectly happy just closing this and leaving it closed if you never want to think about it again or we can explore some ways to get debugging up on these new, super low-end parts. Please don't let me add to your crank factor. Rest up and be well! |
Definitely re-opening the issue right now. I really think that all of this is overkill. Considering the max flash size is only 16kB, and there is no time constraint on timing outside of a per-bit time constraint, there's no issues with underruns, etc. I.e. you can send one bit, then 1ms later send the next bit, no harm. There's just a very straightforward path to having a proper debugger. A big part of me is hoping to just re-use the existing WCH Link-E dongle since they are widely available and <$5. But, I keep running into limitations on the firmware running in it and it's getting very frustrating. |
Interesting. Once you throw careful timing out the window, it gets a lot
easier to prototype/develop the whole thing on your Real Computer with a
USB-attached GPIO device like the CH347 or the DTR pin on a CH340 or
FTDIFriend or /dev/gpio on a Pi or other such device, free of the pain of
embedded systems dev and just writing python to fling bits over USB or
/dev/gpio or whatever.
I only really started going down this rabbit hole myself when the
WCH-Links couldn't be bought ... and once they became available, they were
six weeks of shipping away. I agree now that Link-E's are plentiful and
have the secret sauce for both 003 and the bigger chips that this is just
increasingly a curiosity.
Patrick made an odd tweet day on programming these that optimized down to
"use our closed source tool to do it."
…On Tue, Feb 28, 2023 at 3:37 PM CNLohr ***@***.***> wrote:
Definitely re-opening the issue right now.
I really think that all of this is overkill. Considering the max flash
size is only 16kB, and there is no time constraint on timing outside of a
per-bit time constraint, there's no issues with underruns, etc.
I.e. you can send one bit, then 1ms later send the next bit, no harm.
There's just a very straightforward path to having a proper debugger.
A big part of me is hoping to just re-use the existing WCH Link-E dongle
since they are widely available and <$5. But, I keep running into
limitations on the firmware running in it and it's getting very frustrating.
—
Reply to this email directly, view it on GitHub
<#2 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCSD3YPOG7IYUFAS4S4ALLWZZVY5ANCNFSM6AAAAAAVDHUHZ4>
.
You are receiving this because you modified the open/close state.Message
ID: ***@***.***>
|
I have it all working with the ESP32-S2 while it remains connected to USB. https://github.com/cnlohr/esp32s2-cookbook/blob/master/idf_sandbox/tools/ch32v003_swio_interface_test/ch32v003_swio.h Just by connecting a 10k ohm resistor to Vcc and connecting the pin to the SWIO pin on the CH32V003. It should be pretty straightforward from here. As a note: I did find that the CH32V debug interface DOES care if you totally mangle your timing, as it will time out. But the timing only needs to be precise on the 41-bit transaction level. |
https://github.com/NgoHungCuong/NHC-Link042 |
This has been thoroughly completed at this point and is well understood. Closing the issue. |
* one GPIO library to rule them all * GPIO example makefile transfer * GPIO README.md video upload * Update README.md * Update README.md * GPIO library path recitified * GPIO pretty paths please * platformio.ini removed GPIO_analogRead test * GPIO removed implementation block (unused) * restoring blink.bin cnlohr#1 * restoring blink.bin cnlohr#2 * GPIO_branchless added branching digitalWrite (sometimes necessary) --------- Co-authored-by: recallmenot <edmund.raile@proton.me>
* one GPIO library to rule them all * GPIO example makefile transfer * GPIO README.md video upload * Update README.md * Update README.md * GPIO library path recitified * GPIO pretty paths please * platformio.ini removed GPIO_analogRead test * GPIO removed implementation block (unused) * restoring blink.bin #1 * restoring blink.bin #2 * GPIO_branchless added branching digitalWrite (sometimes necessary) * GPIO fixed PWM fade flicker --------- Co-authored-by: recallmenot <edmund.raile@proton.me>
Good luck in decoding One Wire. They've announced they'd be publishing it just after the CNY ended, so let's see how that goes.
Once you figure out the encoding, I wonder if it bears any resemblance to the Official RISC-V debug protocol.
https://riscv.org/wp-content/uploads/2019/03/riscv-debug-release.pdf
Clock recovery and serialization are, of course, tough nuts to crack, but it'd be nice if somme part of it matched the official specs. Their changes in OpenOCD indicated that it might resemelbe the RISC-V 0.1.3 debug spec, IIRC.
Good luck!
(and please just close this if you don't dig conversations in your issue tracker)
The text was updated successfully, but these errors were encountered: