<rigid>
hm, nah. that seems to be solved already. now trying really short directly soldered connections
<Haohmaru>
do you have sane SWD port on the target? pull resistors?
<Haohmaru>
no idea about your chip, but for those i've dealth with, pull resistors are needed on the SWD signals
<PaulFertser>
rigid: hi you didn't highlight me so I had no clue I should check
<PaulFertser>
rigid: is pico powered externally?
<PaulFertser>
rigid: almost certain something is wrong on hardware level there on your desk.
<PaulFertser>
rigid: if you connect target's RESET you should either tell about it OpenOCD (reset_config srst_only) or do not connect it.
<rigid>
Haohmaru: not sure, it's a raspberry pico board. will check
<Haohmaru>
if someone else made the board, and if they aren't dumb, then it should be fine
<rigid>
PaulFertser: no worries, whenever your time allows :) will check the reset_config
<PaulFertser>
rigid: just hilight me on every message directed to me, that's fine
<rigid>
i'll check the hardware setup with the scope. i guess I should see a clock and some data levels on the pico pcb
<Haohmaru>
but true, if you don't actually supply power to the chip, and the debugger doesn't either, the chip may kinda sorta get *some* power from the mere SWD signals and half-work
<rigid>
ok
<PaulFertser>
jlink doesn't supply power to the target
<rigid>
it's powered by USB and the jlink VCC pin
<PaulFertser>
jlink vcc pin is used for input, not output
<Haohmaru>
rigid, will it stay powered after you disconnect the debugger completely... that's the question
<PaulFertser>
rigid: and do you confirm the ROM USB bootloader works?
<rigid>
Haohmaru: yes it will
<rigid>
PaulFertser: yes. i.e. it will register as a mass storage device when the program button is held down. That's how I flashed the debug build of my program
<rigid>
ok, short connections didn't seem to help. adding "-c 'reset_config srst_only'" also didn't change anything.
<rigid>
will fetch the scope now
<Haohmaru>
you didn't mix up the SWD connections, did you?
<rigid>
hm, lemme doublecheck
<Haohmaru>
particularly SWCLK and SWDIO
<PaulFertser>
Or pins on the JTAG header.
<Haohmaru>
yeah, double-row connectors can sometimes be confusing ;P~
<Haohmaru>
i read stuff here and there, and wasn't 100% sure what's going on, so i bought the middle option with their special cable, but not the full $$$$ option with all the fancy stuff
<Haohmaru>
PaulFertser, also, if you're making a debugger but you're cheap, you might put a pin header/socket instead of an IDC connector
<Haohmaru>
i put a socket on my debugger and made an IDC tab with the PCB
<Haohmaru>
i checked the resultant pinout like 4 times, so i hope it's correct ;P~
<PaulFertser>
:)
<Haohmaru>
btw, i ordered it, and the parts... i just forgot to buy a 2x5 flat cable >:(
Deneb has quit [Quit: Leaving]
<rigid>
I got another problem investigating a freeze of my RP2040. There are multiple warnings/errors and I'm not even sure if it's an openocd issue :-/
<rigid>
a search for "A non multidrop capable device connected?" only yields 5 results, none seem to be helpful at first glance
<PaulFertser>
Error: Failed to send data to device: LIBUSB_ERROR_PIPE
<rigid>
basically I'd like to find out, why the MCU halts when it halts (sometimes it takes hours)
<PaulFertser>
Something goes bad about connection _to jlink_
<rigid>
strange. it's a normal USB cable. hm...
<PaulFertser>
Is it a jlink clone? Still should work ok...
<PaulFertser>
Probably bad buggy firmware version in this jlink?
<PaulFertser>
Any errors in host dmesg? And is it a normal bare metal machine or a VM?
<rigid>
PaulFertser: i have been connected via a hub. now connected directly and the LIBUSB_ERRORs are gone.
<rigid>
still get "Error: Failed to select multidrop rp2040.dap0" but a lot less errors
<rigid>
PaulFertser: i updated the gist. I guess it looks ok-ish
<rigid>
it crashes much faster now, tho
<rigid>
s/faster/sooner/g
<PaulFertser>
rigid: looks like your target MCU has watchdog or something, probably disables SWD pins by remapping or sleeps or similar.
<PaulFertser>
Or probably this rpi isn't supported that well.
<PaulFertser>
I suggest you start simple, "reset halt" and step from there.
<Haohmaru>
interestingly i ran a samd20 SPI at 24MHz, it gave errors in the communication with the slave... then i set stronger drive strength on the SPI output pins... now it works, cool
flatmush has quit [Ping timeout: 264 seconds]
flatmush has joined #openocd
rigid has quit [Read error: Connection reset by peer]
rigid has joined #openocd
Kerr has joined #openocd
Haohmaru has quit [Quit: saionara]
Hawk777 has joined #openocd
nerozero has quit [Ping timeout: 268 seconds]
rkta has quit [Remote host closed the connection]
rkta_ has joined #openocd
rkta_ is now known as rkta
Deneb has joined #openocd
MGF_Fabio has quit [Ping timeout: 268 seconds]
vampi__ has quit [Ping timeout: 256 seconds]
slobodan has quit [Ping timeout: 264 seconds]
mark_feathers has joined #openocd
Deneb has quit [Quit: Leaving]
electricworry has quit [Ping timeout: 264 seconds]