Reading symbols from main.elf... 0xffffffff in ?? ()

[prosper00]

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

~/ch32v-base/Projects/prng$ make flash
gdb-multiarch -x gdbinit -ex 'load' -ex 'detach' -ex 'quit' main.elf
GNU gdb (Ubuntu 13.1-2ubuntu2) 13.1
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from main.elf...
0xffffffff in ?? ()

[ewpa]

I've been seeing this too. What is the exact model of your target CH32V003?

[prosper00]

I have the SOP-8 and the TSSOP-20. CH32V003F4P6 and CH32V003J4M6

[ewpa]

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.

[prosper00]

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...

[ewpa]

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'.