Open prosper00 opened 1 year ago
I've been seeing this too. What is the exact model of your target CH32V003?
I have the SOP-8 and the TSSOP-20. CH32V003F4P6 and CH32V003J4M6
With the SOP-8 J4M6 I see this. It can often be resolved by resetting the Pico after the CH32V. My thought is that the CH32V has no nRST pin and the Pico only asserts a reset signal on SWIO at its startup. If the CH32V does not pull the line low then FFFF is all that is read. I did find the QFN more responsive to the Pico programmer.
However at present I am unable to get any of my CH32V003J4M6 chips responding to the Pico. I am waiting for delivery of an S2 and LINK-E, but in the meantime I may try your workarounds in issue #1 using multiple resets.
I don't think it has anything to do with nRST. None of the programmers require the use of nRST, for any of the chips. I wonder if I can figure out how to get PicoRVD to add a reset after flashing...
In my case the issue was caused by an inadvertent clearing of CFGLR on port D. With PD4 now an analog input, programming was an issue until I 'cleared the code flash by power off'.
Occasionally, I get failures to connect to the target. GDB reports as follows (below), and hangs there.
I'm not able to reproduce this behavior reliably - it seems pretty random. What can I do to help troubleshoot?
I've got a logic analyzer handy, if that would be helpful