Comments (14)
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.
from ch32v003fun.
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.
from ch32v003fun.
from ch32v003fun.
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:
- ESP32-S2, -S3
- STM32F042
- ATMega32u2/u4
Charles
from ch32v003fun.
I guess my overall suggestion is - why not just use GPIO with disable/enable interrupts?
from ch32v003fun.
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.
from ch32v003fun.
Also, bleh, sorry for my attitude just a bit of a rough day.
from ch32v003fun.
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!
from ch32v003fun.
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.
from ch32v003fun.
from ch32v003fun.
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.
from ch32v003fun.
https://github.com/NgoHungCuong/1-Wire-CH32V003
from ch32v003fun.
https://github.com/NgoHungCuong/NHC-Link042
CH32V003 flash programming, firmware based on STM32F042F6P6
from ch32v003fun.
This has been thoroughly completed at this point and is well understood. Closing the issue.
from ch32v003fun.
Related Issues (20)
- Wrong definition of funPinMode? HOT 2
- FUN_HIGH and FUN_LOW behave reversed for funDigitalWrite HOT 1
- Convoluted UART_BRR calculation HOT 3
- Redundant `blink[_raw].bin` files source controlled in repo? HOT 11
- TODO For new updates
- Configurable RAM sizes for V20x, V30x HOT 8
- Compilation results in no code HOT 1
- Make minichlink print flash amount HOT 1
- Make semihosting printf speed along if it times out.
- Empty LD file on missing build tools HOT 2
- prebuilt blink.bin example doesn't seem to work on a CH32V003 board HOT 1
- PWM 8 KHz 16 bit HOT 11
- Onewire slave
- CH32V003A4M6 SPI? HOT 2
- Is this board right for me? HOT 5
- Are there defined symbolic constants for AFIO_EXTICR register values? HOT 5
- minichlink not detecting esp32 programmer on MacOS. HOT 1
- DISCUSSION - Could this run Klipper ? I think it really could omg HOT 8
- Why does my code stop when I connect minichlink terminal? HOT 8
- v30x blink example don't run if TARGET_MCU_PACKAGE sets to CH32V307VCT6 HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ch32v003fun.