cambrian_invader has quit [Ping timeout: 244 seconds]
cambrian_invader has joined #openocd
zjason has quit [Remote host closed the connection]
zjason has joined #openocd
agent314 has quit [Ping timeout: 258 seconds]
agent314 has joined #openocd
nerozero has joined #openocd
rkta has quit [Ping timeout: 258 seconds]
tsal has quit [Ping timeout: 258 seconds]
_whitelogger has joined #openocd
agent314 has quit [Ping timeout: 248 seconds]
zmatt has joined #openocd
agent314 has joined #openocd
rkta has joined #openocd
agent314 has quit [Ping timeout: 248 seconds]
agent314 has joined #openocd
slobodan has joined #openocd
Haohmaru has joined #openocd
slobodan has quit [Ping timeout: 260 seconds]
Guest91 has joined #openocd
<Guest91>
antto sorry for leaving, I'd be glad to hear how you run openocd directly
<Haohmaru>
i run it from a terminal, it connects to the debugger (daplink in my case), the debugger connects to the chip, and then it starts waiting
<PaulFertser>
Guest91: hi
<Haohmaru>
afterwards, in my IDE i have gdb-multiarch (i'm on debian) configured with "external" or what was it
<Haohmaru>
basically gdb connects via TCP to openocd
<PaulFertser>
Guest91: what exactly is the question?
<Haohmaru>
he wants to debug some cortex-M iirc
<Haohmaru>
and he has some cmsis-dap debugger
<PaulFertser>
Is that cmsis-dap not connected at all to esp32 on board?
<PaulFertser>
Is that cortex-m core powered and not kept in reset externally?
<PaulFertser>
Where are schematics for the board?
<PaulFertser>
And I'd like to see -d3 output from openocd on some pastebin.
<Haohmaru>
my nose tells me either "no power" or "wrong connections" (which may include circuit fault like a short on some of the SWD pins or something
<Haohmaru>
he doesn't run openocd directly but via some crapduino-grade thing iirc, and he was asking how to do all of this more directly (outside the crapduino crap)
<Haohmaru>
this is for my chip, you'll have to change some of the arguments ^
<PaulFertser>
A similar command is in the README already.
<Haohmaru>
PaulFertser, openocd is..... difficult to comprehend for dumb people like me, the first thing i did was check the readme, i eyeballed it for a long long time all over the place, and i could figure what's going on, eventually either i asked here or found some website with a concrete example
<PaulFertser>
But README does have an example at the very beginning.
<Haohmaru>
openocd was just 1 ingredient of the whole operation
<Haohmaru>
i had no idea how the whole thing works
<Haohmaru>
you have: IDE, GDB, openocd, hardware debugger, MCU
<Haohmaru>
x_x
<Haohmaru>
so many planets have to line up for things to work
<Haohmaru>
mmm, "external remote" was the phrase for GDB
<PaulFertser>
extended?
<Haohmaru>
hm, maybe extended, memory no bueno
<PaulFertser>
So Guest91 any update?
<Haohmaru>
basically a mode where GDB connects to a GDB server over TCP or serial or some other way, and in our case openocd acts like a GDB server
<PaulFertser>
Yes, extended-remote is a bit better than regular remote.
<Haohmaru>
afaiu it allows you for example to give your friend a program you wrote, and if he says "it crashes!" you can debug it from your PC while the program runs on his PC and you can be in two different cities ;P~
<Haohmaru>
IDE > GDB (ext remote, client) > TCP/serial > GDB SERVER (this could be openocd) > program
<Haohmaru>
when it's openocd there's usually also some hardware between openocd and the "program"
<Haohmaru>
the TCP connection in the middle allows you to do this over a network, or even the internetz
<PaulFertser>
Sure
<Haohmaru>
so when i was starting, i already knew GDB because my IDE has integration and it just worked™, for "computer programs" i mean... but i had never used "ext remote" and this whole picture ^ was unclear to me
<Haohmaru>
i think he's using some crapduino-grade things which attempt to make things "easy", but when doing so they might often hide away what's actually going on, not showing you the actual picture
<Haohmaru>
because, if it works - it's okay, but when something under the hood doesn't work - you have to figure out what's going on
<Haohmaru>
so, Guest91, besides having to run openocd, the invokation to GDB is not "normal", so you have to also put some arguments there
<Haohmaru>
the normal way is that you invoke GDB and GDB directly fiddles with the program on your computer, there's no "client" and "server" and no TCP/serial connection stuff
<Haohmaru>
we can't do this here because the program actually runs on an MCU, so you have to run GDB on the PC in "ext remote" mode, which makes it a "client", and openocd acts as the "server"
<karlp>
all we know is that their pio command tried to run an openocd flash programming command, and they got a comms failure, likely wiring or power.
<Haohmaru>
yeah, a very early error
Guest75 has joined #openocd
<Guest75>
hey sorry, I haven't had a proper irc client setup in years. so the board. PaulFertser, the board is an arduino uno r4 wifi, which is a renesas (the arduino core) connected to an esp32 which does wifi/blutooth/other functionality, plus appears to flash the renesas. I do not use the Arduino IDE, but platformio, which reuses the toolchain of arduino
<Guest75>
I pasted some configuration, this is the lsusb output whosing the cmsis-dap device https://paste.centos.org/view/21a043f2, this is the effective command used by platformio `openocd -d2 -s /home/Guest95/.platformio/packages/framework-arduinorenesas-uno@1.2.2/variants/UNOWIFIR4 -s /home/Guest95/.platformio/packages/tool-openocd/openocd/scripts -f
<Guest75>
I don't strictly need (I believe) the upload via cmsis, but I haven't dug yet into the openocd documentation to be able to launch the commands directly
<Haohmaru>
if only the "daplink" has power (perhaps from the USB) but the MCU doesn't have power - you can't debug it, can't do anything
<Guest75>
Haohmaru, usb. ADC readings are flaky, so it can be a power issue as well. Some people on the arduino forums noticed that the physical usb port matters
<Guest75>
however the cores boot, it's supposed to work with usb power
<Haohmaru>
wtf, who made this board?
<Guest75>
Arduino, don't ask
<Haohmaru>
hm
<Haohmaru>
well, this is the very first question that needs a clear answer, is the MCU getting proper power or not
<Guest75>
while I try the openocd command, my own firmware is running correctly
<Guest75>
(except for ADC readings, they seem to drift)
<Haohmaru>
the next question is about the connections between the daplink and the MCU, but since it's "on-board" it should probably not be wrong, unless there's some room for user improvisation like jumpers or something
<Guest75>
do you happen to know how to connect the vscode debugger to an external opencd command?
<Haohmaru>
next, what mr PaulFertser said about running openocd with -d3 arguments and pasting the output into some pastebin
<Guest75>
ok, can't do that now, but thanks for the pointers
<Haohmaru>
no idea about that IDE
<Haohmaru>
the IDE itself can be removed from the picture by just manually running GDB from a terminal
<Guest75>
gdb got to be the one from the toolchain?
<Haohmaru>
depends
<Haohmaru>
it has to "know" about the MCU architecture sorta
<Guest75>
it runs a ~/.platformio/packages/toolchain-gccarmnoneeabi/bin/arm-none-eabi-gdb
<Haohmaru>
on debian, the normal "gdb" package gives you a GDB which only talks "PC" programs for linux i think, so for MCUs there's a sepparate package named "gdb-multiarch"
<Guest75>
ok
<Haohmaru>
yeah, arm-non-eabi-gdb sounds like a specialized gdb for arm, so if you have this - it's this that you should use
<karlp>
run this by me again, you've got a usb cable connected to the usb-c port on a uno r4 wifi?
<Guest75>
yes
<Haohmaru>
altho the problem with the "IDR" is afaiu somewhere between openocd and the MCU, so not related to gdb at all
<karlp>
where is this cmsis-dap meant to be then?
<Haohmaru>
one USB port that gives power to the whole board and the DATA lines go to the on-board daplink?
<karlp>
there' no on board dap link in the schematic at least...
<Haohmaru>
huh
<karlp>
the r7fa4m has a pin it can use to say "usb to me please" or "usb straight to the esp32 ples"
<karlp>
the esp32-s3 _does_ have a "usbjtag" module internally, but that's nto cmsis-dap.
<karlp>
hrmm.
<karlp>
I suspect from the offsets,
<Haohmaru>
holy sh*t that schematic x_x
<karlp>
that there's a "bootloader" running on the mcu that implements cmsis-dap for selfprograming itself.
<Haohmaru>
huh
<karlp>
kinda cute, if it works :)
<Haohmaru>
then probably no "debug" right?
<Haohmaru>
because how will that even work
<karlp>
no, it would be for programming only.
<karlp>
I wonder what the thought was, it's just a more complicated setup.
<Haohmaru>
the Tech Specs on the crapduino site say "USB C: Programming Port", no "debug" mentioned anywhere
<karlp>
huh, no. I think it's even more cute.
<karlp>
I think it defaults to giving usb to the esp32,
<karlp>
and the esp32 has a cmsis-dap impl, used for programming the mcu over swd.
<karlp>
see bottom right with the p300_swclk and p108_swdio....
<Haohmaru>
then there are chances that it could be a full daplink with debug abilities, but why don't they say this in the Specs
<Guest75>
https://docs.arduino.cc/tutorials/uno-r4-wifi/debugger/ it's supposed to work. I just tried with the Arduino IDE with an example sketch, and it gives the same error. with my user, I can open the /dev/ttyACM0 device.
<Haohmaru>
i can't look at that schematic x_x
<karlp>
yeah, so you're connecting to the "debugger" but not to the target
<Guest75>
karlp, maybe the pin you're referring to is the one I use to flash a firmware with espflash to the esp32 part?
<Haohmaru>
i saw LEDs, and there's potentially WIFI, could it be that the board eats a lot of current and someone has to tell the USB host about this to be allowed to supply that much current?
<Guest75>
still the board is powered and running correctly? do I need to assume that debugging takes a lot of power?
<Haohmaru>
ah, sorry then
<Haohmaru>
no, debugging shouldn't eat current, WIFI and LEDs do tho
<karlp>
I'd retry that "restore the connectivity firmware" step
<karlp>
then powercycle the board and try again.
* karlp
shrugs
<Guest75>
I already flashed an updated stock firmware
slobodan has joined #openocd
<karlp>
you do you, I'm suggesting retrying that step.
<karlp>
this is arduino shits, it -shouldn't- be this hard...
<Haohmaru>
bottom-right corner, U4, looks like a level-shifter
<Haohmaru>
your MCU's SWD pins are on 17 and 14 there, on the other side it goes to the esp32
<Haohmaru>
pin16 should have 5V, pin5 should have 3.3V
<Guest75>
thanks I'll check that
<Haohmaru>
my point is, i haven't checked, but some of these level shifters that have VCCA and VCCB have some scheme where if one of the two VCCs is "down" (0V) the thing intentionally doesn't work
Guest75 has quit [Quit: Client closed]
<Haohmaru>
oh well
<Haohmaru>
i'm lucky i never went thru this whole crapduino thing