NishanthMenon changed the topic of #openocd to: this is the place to discuss all things OpenOCD | Logs: https://libera.irclog.whitequark.org/openocd/
jn has quit [Ping timeout: 240 seconds]
jn has joined #openocd
jn has joined #openocd
nerozero has joined #openocd
russ has quit [Ping timeout: 240 seconds]
Kerr has joined #openocd
<Kerr> Hey I'm debugging a TM4C123GXL board with openocd and gdb... For some reason my program is ending up in my fault ISR on reset, but I'm not able to see why in the debugger because I can't seem to cause a reset without breaking my debug session
<Kerr> I tried "monitor reset" but that causes "SRST Error" and breaks my session
<Kerr> I've done: "set $pc = *0x04" and "set $sp *0x0", which is what the MCU should do on startup, but the fault does not seem to occur in this case...
<Kerr> also, the fault only occurs when enabling optimizations in the compiler
crabbedhaloablut has joined #openocd
<Hawk777> Can you “monitor reset halt”?
<Hawk777> If it works, that should place the program counter on the first instruction out of reset.
<Kerr> different error message, still breaks my session
<antto> on most MCUs i've seen, changing the program counter to "the beginning" is not equal to a real MCU Reset
<antto> so there could be side-effects
<Kerr> As I've seen. I'm trying to figure out how to do a real reset, and be able to start from the beginning
russ has joined #openocd
<Kerr> In any case, I figured out the source of my bus fault: A peripheral was not ready in time, after being enabled, before I began configuring it. I added the check for it to be ready. Presumably the issue only occurring with optimizations on was because it was ready by happenstance before.
<Kerr> But I'd still like to be able to reset my MCU completely and start from the beginning . If anyone has suggestions, I'd love to hear them. (That said, I'm going to sleep, but will leave the channel open)
Hawk777 has quit [Quit: Leaving.]
Kerr has quit [Remote host closed the connection]
<PaulFertser> Kerr: "mon reset halt" should do it but some targets are problematic. I thought that old TM4C isn't but who knows.
<PaulFertser> A reasonable option in that case is "start" (it's just "tb main + run" essentially).
<PaulFertser> (I knew Kerr left)
Kerr has joined #openocd
<Kerr> PaulFertser: I saw what you said when checking logs
<PaulFertser> Kerr: also, do you have that GDB script to decode faults?
<PaulFertser> Kerr: btw, OpenOCD reset counts on either SRST being physically connected and enabled in reset_config or on SYSRESETREQ bit (which doesn't need SRST and then you shouldn't enable SRST for it to be used)
<Kerr> Here is how I'm launching openocd and gdb atm: https://pastebin.com/eb9Pkk9B
<PaulFertser> Kerr: have you considered using a more common debug adapter instead of that weird on board ICDI ?
<Kerr> now sure what you mean by GDB script to decode faults
<Kerr> Vaguely, but I'm not entirely sure what is compatible with this chip/board
<PaulFertser> Kerr: btw, I do not like your way of starting GDB, it just jumps to some location but the target state is not defined by anything at that moment.
<PaulFertser> Kerr: any SWD should work.
<Kerr> PaulFertser: Ah, yeah, I should set the stack pointer first also, but also all of the target peripherals are not in a fresh state - that's why I'm trying to figure out a proper reset
<Kerr> That was just a hack to get to a point where I'm waiting in main so I can look at other things going on
<PaulFertser> Kerr: proper reset should happen with "run" or "start" command.
<Kerr> I'm in an embedded system class at uni. I'm going the "hard way" by not using the tivaware libraries or code-composer studio
<PaulFertser> But probably ICDI support regressed since then.
<PaulFertser> I'd connect stlink clone instead.
<Kerr> I think I have one of those around. I read that they only work with stm products though?
<PaulFertser> stlink v3 has some abusing limitation. stlinkv2 does not.
<Kerr> Like there were some hacking efforts to get them to work as general purpose SWD, IIRC?
<Kerr> Noted!
<PaulFertser> stlink v2 even with older firmware works with SWD just fine, but doesn't expose AP-level operations so you can not e.g. unlock Kinetis MCUs with it. But newer firmware supports DAP mode commands so that shouldn't be a problem.
<PaulFertser> Some old stlink clones miswired the SRST pin, so when in doubt just check it really toggles (when enabled) with an oscilloscope or something.
<Kerr> Is there are non-abusive general SWD debugger on the market that doesn't cost more than a nice dinner?
<Kerr> How old are we talking? I've had my stlink v2 for about 8 years
<Kerr> Also I've been wondering the same question about JTAG
<Kerr> c
<PaulFertser> Kerr: do you have original or clone?
<Kerr> clone. I think I paid $0.70 with free shipping from aliexpress
<Xogium> oof that's suspiciously cheap :D
<Kerr> well back then the stm32f103 on it was like 20 cents
<Kerr> i hate this covid level prices
<PaulFertser> Kerr: I like having TUMPA handy for JTAG.
<PaulFertser> https://www.diygadget.com/jtag-cables-and-microcontroller-programmers/tiao-usb-multi-protocol-adapter-jtag-spi-i2c-serial 40 bucks but it has good buffer IC which is fast and wide voltage range, also RS-232 and UART pins can be handy.
<PaulFertser> Supported by flashrom too for SPI NOR memory.
<Kerr> tyvm
<Kerr> now i really need to sleep, will leave channel open
<PaulFertser> Cloned JLink (or even original EDU version) can be good for educational purposes too.
Foxyloxy has quit [Quit: Textual IRC Client: www.textualapp.com]
Foxyloxy has joined #openocd
bvernoux has joined #openocd
bvernoux has quit [Read error: Connection reset by peer]
linuxdude has joined #openocd
<linuxdude> hello
<PaulFertser> Hi
<linuxdude> i have a question, is the s32k344 supported in openocd
<PaulFertser> linuxdude: you came and left right away, no chance to help you
<PaulFertser> linuxdude: one is supposed to stay on channel till someone answers
<linuxdude> and if it isnt, how would i go about making it supported
<linuxdude> sorry, i was on my phone
<PaulFertser> linuxdude: what is it, an MCU? What core?
<linuxdude> cortex m7f
<linuxdude> dual core
<linuxdude> it s an mcu
<PaulFertser> linuxdude: you can debug it without doing anything other than a minimal config. But changing the flash is a different matter.
<linuxdude> wdym changing the flash?
<linuxdude> also how minimal should the config be
<linuxdude> what does it need?
<PaulFertser> linuxdude: are you connecting with JTAG or SWD? Either way you need to define swj access port, then dap, then the core.
<linuxdude> SWD with the ft2232h
<PaulFertser> linuxdude: two cores. There're many other cortex-m MCU's already supported so that can be used as example.
<PaulFertser> linuxdude: like e.g. nrf51.cfg before flash specification
<linuxdude> i see
<PaulFertser> linuxdude: writing to flash requires making a target-specific flash driver for OpenOCD.
<linuxdude> is that supplied with the board?
<linuxdude> or do we need to make it?
<PaulFertser> linuxdude: the latter unless someone has already done the job
<linuxdude> do you know how would i go about making a flash driver for openocd for this chip?
<PaulFertser> linuxdude: do you have register-level documentation for the flashing procedure in the datasheet?
<linuxdude> i don't think so but i m not sure
<linuxdude> i have the datasheet and the reference for the chip
<linuxdude> but i m not sure if its register level documentation
<PaulFertser> linuxdude: how do you plan to write software for this MCU?
<linuxdude> i am currently in a uni club to make a sattelite using this chip
<linuxdude> and i am tasked with making the debugging/flashing work with it
<PaulFertser> That sounds great. But how do you plan to actually enable and drve the peripherals etc?
<linuxdude> i didnt look into that yet
<PaulFertser> Does the chip have some ROM bootloader? Probably you can flash via the bootloader instead, and debug with OpenOCD?
<linuxdude> let me verify that
<PaulFertser> linuxdude: so you're going to develop a cubesat? Sounds awesome. Do you have experienced MCU developers on the team?
<linuxdude> yes
<linuxdude> exactly
<PaulFertser> lockstep core wow
<PaulFertser> linuxdude: I suggest you just get them involved here in the discussion.
<linuxdude> i ll tell them later, rn they are not online
<PaulFertser> It's just that OpenOCD is essentially doing the same thing as MCU firmware, so flashing and debugging topics are very closely related to developing firmware for it.
<linuxdude> i see
<linuxdude> rn we are more in an exploration/making docs phase
<linuxdude> just to see what is feesable and not
<linuxdude> it has a bootloader
<linuxdude> so it should be easy to flash the software in it
vampirefrog has joined #openocd
Hawk777 has joined #openocd
nerozero has quit [Ping timeout: 255 seconds]
Hawk777 has quit [Quit: Leaving.]
zear has quit [Quit: bye]
zear has joined #openocd
Hawk777 has joined #openocd
linuxdude has quit [Ping timeout: 255 seconds]
crabbedhaloablut has quit []
<karlp> there's someone in the orbuculum channel doing some things with an s32, mubes went and ordered one for giggles too, it has some.... special... behaviour iirc.
<antto> slow cortex-m7f... by NXP, in quite some WTF package o_O
<antto> is that like a dual-row QFP or what