aappleby / picorvd

GDB-compatible RISC-V Debugger for CH32V003 that runs on a Raspberry Pi Pico
MIT License
173 stars 11 forks source link

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

Open prosper00 opened 1 year ago

prosper00 commented 1 year ago

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 commented 1 year ago

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

prosper00 commented 1 year ago

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

ewpa commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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