NishanthMenon changed the topic of #openocd to: this is the place to discuss all things OpenOCD | Logs: https://libera.irclog.whitequark.org/openocd/
sys64738 has quit [Ping timeout: 252 seconds]
sys64738 has joined #openocd
joconor has quit [Ping timeout: 276 seconds]
joconor has joined #openocd
joconor has quit [Quit: ZNC 1.8.2 - https://znc.in]
joconor has joined #openocd
jn has quit [Ping timeout: 265 seconds]
jn has joined #openocd
tsal_ has joined #openocd
tsal has quit [Ping timeout: 264 seconds]
joconor has quit [Quit: ZNC 1.8.2 - https://znc.in]
joconor has joined #openocd
gamiee has quit [Ping timeout: 265 seconds]
gamiee has joined #openocd
braunr has quit [Remote host closed the connection]
joconor has quit [Ping timeout: 260 seconds]
joconor has joined #openocd
nerozero has joined #openocd
joconor has quit [Quit: ZNC 1.8.2 - https://znc.in]
joconor has joined #openocd
Haohmaru has joined #openocd
Hawk777 has quit [Quit: Leaving.]
braunr has joined #openocd
JakeSays_ has joined #openocd
JakeSays has quit [Ping timeout: 252 seconds]
JakeSays has joined #openocd
JakeSays_ has quit [Ping timeout: 252 seconds]
JoseT has joined #openocd
<JoseT> Hi All, I would like to try out a debug probe which supports latest cmsis-dap version for adding a TI device in openocd. I would appreciate any suggestions :).
ScottBakula has joined #openocd
<Haohmaru> you already have a debugger or you want suggestions for what debugger to get?
braunr has quit [Ping timeout: 255 seconds]
braunr has joined #openocd
<JoseT> I am looking for a debugger supporting cmsis-dap fw version 2.1.1 or atleast any version above 2.0.0
<Haohmaru> no idea, the unexpensive ones i know are below 2.0 because they don't have the Bulk thing
<Haohmaru> and also, they probably use too small MCUs which might prevent them from having fancier firmware
<Haohmaru> hm, i think i had seen one with Bulk advertised, lemme see if i can find it
<Haohmaru> i think it was this one: https://github.com/wuxx/nanoDAP/tree/master
<JoseT> Thanks Haohmaru. Not sure if someone tried MuseLabs debugger with openocd. I could find some other in my search explicitly mentioning about 'works with opecocd'.
joconor has quit [Quit: ZNC 1.8.2 - https://znc.in]
<Haohmaru> all daplinks should generally work with openocd, i mean, no matter who made them... so if there is one daplink v2 that works with openocd, then another daplink v2 should too, afaiu
joconor has joined #openocd
<Haohmaru> unless you're interested in some particular feature which itself might be the problem
<Haohmaru> for me, v2 is interesting because the USB Bulk thing is said to allow faster flashing speeds
<Haohmaru> i also went to make my own daplink (with a cortex-M0+ but with enough flash and RAM to allow interesting features)
<Haohmaru> but it's unfinished
<JoseT> yes full speed support is the key difference but I can see fast clock mode also in latest version2.1.1
<Haohmaru> you mean fast SWCLK?
<Haohmaru> the USB Bulk scheme of daplink should work with openocd
<Haohmaru> i mean, since a few openocd versions ago at least
<Haohmaru> the other thing that can speed things up is if the USB on the MCU is High-Speed (480M)
<Haohmaru> no idea what firmware it has, but its USB is High-Speed
<ScottBakula> hello, do you have a flipper zero ?
<ScottBakula> if you have one you can use it as a cmis-dap
ScottBakula has quit [Quit: Leaving]
ali1234 has joined #openocd
<ali1234> my stm32f103 reports a flash size of 0 and refuses to halt. is it dead?
<Haohmaru> reports?
<Haohmaru> did you buy it from some fishy place?
<ali1234> no?
<Haohmaru> okay, show some evidence of the "report", preferably in a pastebin if it's too long
<ali1234> openocd says "Warn : STM32 flash size failed, probe inaccurate - assuming 512k flash"
<ali1234> and st-info says "flash: 0 (pagesize: 2048)"
<Haohmaru> okay, now wait until the experts wake up
<ali1234> this is usually associated with the chip being read-protected
<ali1234> which is undone by running "stm32f1x unlock 0"
<ali1234> this is supposed to trigger a full erase
<ali1234> however it just says "target not halted" instead
<Haohmaru> ah, so it is a potentially legit state
<Haohmaru> not that unlocking might involve some very particular "ritual" of operations and conditions
<ali1234> and issuing a "halt" command results in "Error: timed out while waiting for target halted"
<Haohmaru> * note ^
<ali1234> the chip type is reported correctly though, in st-info anyway
<ali1234> so it is at least partially alive
<ali1234> i do have nrst connected, but the config for for stlink forces srst only
<ali1234> i tried changing it to trst only, but it made no difference
<Haohmaru> wait for the ST experts to say, if you get inpatient you could try an stm32-specific channel too
<ali1234> the board worked fine for like 3 years btw. then one day it just stopped working
<ali1234> i suspect it is just dead
<ali1234> i have had basically nothing but problems with stm32 though, so who knows?
<ali1234> wrt flashing them that is. this board had a bootloader for that
<ali1234> so i never had to use it with openocd/swd before
<Haohmaru> you're aware there are unfortunately stm32 clones, even lousy knock-offs, but basically different chips disguised as real ones
<ali1234> yes
<ali1234> there are also knock off stlink probes, and that is what everyone seems to use, but i am using a real one
<Haohmaru> well, that's as far as i can help, wait for the experts
nerozero has quit [Ping timeout: 248 seconds]
JoseT has quit [Quit: Client closed]
Haohmaru has quit [Quit: saionara]
<PaulFertser> ali1234: try to do "reset halt" with SRST connected and enabled.
<PaulFertser> Then do "stm32f1x mass_erase 0"
<ali1234> "reset halt" says "Error: timed out while waiting for target halted"
<ali1234> and "stm32f1x mass_erase 0" says "TARGET: stm32f1x.cpu - Not halted"
<PaulFertser> ali1234: but do you have srst connected and enabled?
<ali1234> what do you mean by "enabled"?
<PaulFertser> With "reset_config srst_only connect_assert_srst"
<ali1234> same
<PaulFertser> ali1234: do you have the line physically connected?
<ali1234> i have a wire from nRST on the debug probe to RESET on the target board
<PaulFertser> ali1234: and is it original stlink? BTW, do you probably have a jumper or other way to manipulate BOOT0 pin on the target?
<ali1234> the debug probe is the debug section of a nucleo board
<ali1234> the target does not have boot jumpers
<PaulFertser> ali1234: what happens if you pull reset line to GND permanently with tweezers or something and start openocd while doing that?
<ali1234> exactly the same thing
<PaulFertser> ali1234: then I suspect your target's RESET is not connected to MCU reset!
<ali1234> no, it definitely is
<ali1234> the board has a reset button
<ali1234> and when the board worked, pressing it reset the board
<ali1234> and according to the schematic, it is connected to MCU reset
<PaulFertser> Please pastebin output when you're connecting OpenOCD with reset button held.
<PaulFertser> ali1234: and what happens if you release the button after starting but before that message about timeout is shown?
<PaulFertser> Try few times.
<PaulFertser> ali1234: also measure the voltage on the reset line. Probably the reset button got stuck pressed so the target is always under reset.
<PaulFertser> The MCU is certainly not dead.
<ali1234> the MCU may not be but i am not sure about the flash
<ali1234> ah it's alive!
<ali1234> i put a 4.7k resistor between reset and 3.3v and now openocd sees it
<ali1234> "stm32x mass erase complete"
<ali1234> i thought stm32 wasn't supposed to have a pull up on reset
<ali1234> but maybe the fake ones need it
<PaulFertser> Never heard about any clone needing it.
<PaulFertser> Probably there's something else on the board other than the button that might be pulling it down?
<ali1234> not according to the schematic
<ali1234> maybe on the probe board though?
<ali1234> the probe is a nucleo and it works fine with the on-board f103
<ali1234> only when using the external header to target board does this happen
<PaulFertser> Weird story.
<PaulFertser> But well, now you know the MCU works and you can reflash it.
<PaulFertser> Is it an FDM printer board?
<ali1234> yes
<ali1234> i reflashed it but it still doesn't work :(
<PaulFertser> But now you can debug, SWD is not just for flashing.
<ali1234> yes
<PaulFertser> I still recoommend measuring target board voltage etc.
<ali1234> thing is, it was working fine, then it just froze, and after reset it does nothing
<ali1234> it's not like i flashed a bad firmware to it
<ali1234> however the firmware does store settings on flash, so it may have corrupted itself. that's the only thing i can think of that isn't hardware damage anyway
<PaulFertser> Probably one of the drivers failed short.
<ali1234> but mass_erase should have fixed that
<PaulFertser> Step by step and see where it gets stuck.
Hawk777 has joined #openocd
joconor has quit [Read error: Connection reset by peer]
joconor has joined #openocd
<PaulFertser> borneoa___: hey, regarding 34ec5536c0ba3315bc5a841244bbf70141ccfbb4 deprecating ST-Link HLA support. I admit I have never updated ST-Link firmware and I do not even have a good clue how to do that.
<PaulFertser> I just plugged in an old (well, it's newer than those older stlinkv2 adapters, it's 2.1) Nucleo and your message is puzzling me.
<borneoa___> PaulFertser: hey. The HLA has big limitations for new SOCs dual core. I would really like to drop HLA for stlink, but I first want to have more feedback on dapdirect. For update there is a tool STSW-LINK007 in st website, but it's a website full of JavaScript. And to run it on Linux you need jre installed. AUR has it
<ali1234> it's alive.. it does seem to be that something is constantly asserting reset
<PaulFertser> borneoa___: I understand the motivation but I would really like to have there in the message some easy instructions that could be followed on any POSIX system that can run OpenOCD. Please...
<PaulFertser> ali1234: probably it is the button after all? Or the brown-out detector, have you checked the Vcc on MCU?
<ali1234> the same pull up resistor on reset makes the normal firmware work - after unplugging the debug probe so it can boot normally
<PaulFertser> borneoa___: iirc the protocol of communicating with stlink bootloader is well-known by now. So a link to a sensible (not in Java) utility plus a link to download newer version (without JS) would be appropriate I think.
<ali1234> so it can't be a short
<PaulFertser> borneoa___: or probably do not deprecate the hla driver and instead give a suggestion in the error message of the dap direct code to just switch to stlink-hla config.
<ali1234> all axis and heaters are working correctly too so it isn't them
<borneoa___> PaulFertser: agree, let me review the errors message to a more friendly one.
<ali1234> i did notice that the extruder gear produced some metal powder... maybe some got on the board and made a very high resistance short
<borneoa___> PaulFertser: I never used other tools than ST one for the fw update, but what you say is interesting. I will search for such alternative
<PaulFertser> borneoa___: and something needs to be done to ST site for firmware download if at all possible. Re the tools, I remember reading https://lujji.github.io/blog/reverse-engineering-stlink-firmware/ but I can not remember if there's a sane (read not requiring JRE) tool for updating.
<PaulFertser> borneoa___: interesting, it compiles but doesn't know the PID, guess it's not in "DFU" mode and it's unclear how to switch it into that.
<borneoa___> PaulFertser: I think reset the MCU of stinks to enter dfu. Maybe you need to open the plastic cover
<PaulFertser> borneoa___: I thought I'm supposed to be able to update even remotely if it's already running stlink firmware.
<borneoa___> PaulFertser: agree, but if the tool cannot do it... With OpenOCD code, the DFU should be one of the modes set at the beginning of the connection
<PaulFertser> We can fork and make our own tool that can switch to whatever mode needed, but where to get the new firmware from? The ST website doesn't seem to be friendly enough for that anyhow.
<borneoa___> PaulFertser: iirc the java blob from ST can be unzipped and has the binaries , one for each configuration of stlink
<zapb_> borneoa___, this change to stlink dapdirect seems to be a breaking change, no? We make a big effort to be compatible with old hardware, systems etc. Why did we move that fast with stlink dapdirect?
<borneoa___> PaulFertser: but I don't know if are the same needed by that tool
<PaulFertser> borneoa___: that tool seems to be expecting non-encrypted files for running homebrew on stlink essentially.
<borneoa___> zapb_: the first stlink fw that supports dapdirect is already 10 years old
<PaulFertser> Switching to dapdirect by default is probably fine but deprecating it altogether given the situation doesn't feel right.
<zapb_> borneoa___, okay, I did not know this. sounds fair to change but wouldn't be a fallback to the old HLA + deprecation warning possible?
<PaulFertser> People tend to use their setups for many years without updating firmware on jtag adapters without explicit need to avoid breaking it for nothing.
<zapb_> I never updated my stlink tbh, sometimes my j-link but also very rarely
<borneoa___> I checked for long time for a way to implement an automatic fallback, but in OpenOCD HLA target is initialized earlier that the adapter and I cannot test the adapter earlier. I think moving to a warning with the instructions for a manual fallback could be easier
dliviu has quit [Quit: Going away]
dliviu has joined #openocd
<zapb_> borneoa___, okay, check
noarb has quit [Ping timeout: 272 seconds]
noarb has joined #openocd
ScottBakula has joined #openocd
jn has quit [Ping timeout: 265 seconds]
jn_ has joined #openocd
joconor has quit [Quit: ZNC 1.8.2 - https://znc.in]
joconor has joined #openocd