07:57 <PaulFertser> maribu[m]: the usual OpenOCD idea is that prior to flashing "reset init" is executed (it's "reset halt" and then running the reset-init config-defined handler). It's also performed automatically by default when you "load" from GDB.

07:58 <PaulFertser> maribu[m]: good to know it doesn't work properly on some TI MCUs.

08:01 <maribu[m]> Hmm, I think RIOT's script is doing both reset init and reset halt. I have the feeling that some degree of cargo culting is present there. It would be good to know if that was to work around some issue with one of the myriad of boards supported, or just an uninformed decision.

08:03 <PaulFertser> maribu[m]: it makes sense to do "reset halt" after flashing to bring the device to basically power-on-reset state and halt it right there.

08:04 <PaulFertser> Using just halt before flashing is not reliable: what if the target firmware has enabled some interrupts? They might get triggered while the helper "algorithm" is executed on target during the flashing.

08:05 <PaulFertser> (unless cc26xx flash driver doesn't use any target algorithms at all, but then it would be quite slow)

08:06 <maribu[m]> It is done prior flashing in thay script. And after reset halt the JTAG communication fails (invalid ACKs). The flash contents remain unchanged and the board will boot the old image on a reset.

08:07 <PaulFertser> For some targets additional non-standard trickery is needed to get "reset halt" to work.

08:07 <maribu[m]> Would a reset init followed by a halt work?

08:07 <PaulFertser> E.g. psoc4.cfg :)

08:08 <maribu[m]> Likely it would race against the firmwire installing IRQs, right?

08:08 <PaulFertser> maribu[m]: depends on whether the target really resets and whether the target firmware starts executing and setting up IRQ handlers and changing other essential operational states.

08:09 <PaulFertser> Depends on how exactly and why "reset halt" fails.

08:09 <maribu[m]> Maybe that's the reason for the wait-in-reset feature of the ICEPick. It would allow working around a bug in reset halt...

08:10 <PaulFertser> Might be.

11:21 <maribu[m]> borneoa_: Thanks for the comments. The OR1K CRC32 and the QN908x CRC32 are indeed identical, except for a final xor with `0xffffffff` in the QN908x. It does make sense to not have the final xor in it, as it would allow computing the CRC incrementally one chunk of data at a time (and using the result of the last chunk as the seed for the next chunk).

11:22 <maribu[m]> (It will be trivial to just do the final xor operation on the return value of the CRC32 in the QN908x code.)

11:29 <borneoa_> maribu[m]: you are welcome. I don't want to push too much rework on your own, as you are mainly taking care of someone else patch, but I also see thinks that can be improved there. So thanks for your time

13:02 <PaulFertser> maribu[m]: "but the zephyr patch that adds Qreset_config srst_once" I think you meant srst_only there. The idea is that when target is sane and you have debug adapter with hardware reset line you connect it and tell OpenOCD to always use it whenever reset is needed. That makes it possible to reset even the sleeping target or a one that has SWD pins muxed away. When hardware reset line isn't

13:03 <PaulFertser> connected then reset_config shouldn't specify srst of course. In this case Cortex-M targets will be resetted using a special bit in a system register: SYSRESETREQ.

13:04 <PaulFertser> maribu[m]: for normal targets "reset halt" works this way: OpenOCD asserts reset line and then uses SWD to configure vector catch on reset exception, then deasserts reset. This way the target is stopped before executing the first instruction even.

13:05 <PaulFertser> Ah, that's when you have "srst_nogate" in reset_config. Default is srst_gates_jtag, in that case the vector catch is configured before reset is asserted.

13:07 <PaulFertser> maribu[m]: for some stubborn targets it's often ok to do "reset; halt" instead (the first reset implies run, so you might be racing against the target firmware).

13:08 <PaulFertser> Usually the hardware vendor describes a special procedure in the datasheet if the regular vector catch can't be used for whatever reason (e.g. when external resets also fully resets the internal debug circuity).

13:08 <PaulFertser> maribu[m]: I hope your debug logs with CC26xx make more sense to you now.

13:17 <maribu[m]> Sounds like "icepick_c_enable_wait_in_reset; reset; halt" would like be the best option. (Note icepick_c_enable_wait_in_reset is not yet implemented in target/icepick.cfg yet. I do have a branch for that. I will test a bit to see that it indeed works reliably without racing the target firmware anymore and then push it to gerrit for review.)

13:49 <Haohmaru> can openocd be used as merely a flashing tool, like.. from a script?

13:50 <Haohmaru> "connect to debugger, flash .elf, quit"

13:50 <Haohmaru> and without involving gdb

14:10 <maribu[m]> Yes. This is what we at RIOT are doing. E.g. here is the relevant part of a shell script that does this: https://github.com/RIOT-OS/RIOT/blob/cc0371c7122dcb4be97caef73120eca957cca1d4/dist/tools/openocd/openocd.sh#L359-L376

14:12 <maribu[m]> Note that this script has lots of configuration knobs. Every time a new crazy MCU gets added that requires a further custom workaround and the previous knobs didn't scratch the issue, a new knob to gets added. So likely you can trim that down a bit for your use case.

14:13 <Haohmaru> hm, invoking openocd with "sh" ?

14:42 <Haohmaru> ooh, it seems to work, thanks maribu[m]

15:08 <PaulFertser> maribu[m]: if you figure out the right procedure it should be possible to make a suitable reset handler in Tcl so that "reset halt" would do the right thing on that target too.

15:08 <maribu[m]> Haohmaru: That is one of the things you may want to trim down ;)

15:08 <PaulFertser> Haohmaru: see "program" in the official manual.

15:10 <PaulFertser> maribu[m]: some OpenOCD flash drivers are written under assumption that "reset init" is used, not "reset halt".

15:11 <Haohmaru> well, i made a much shorter script

15:14 <Haohmaru> https://paste.debian.net/hidden/0e13e560/

19:14 <maribu[m]> One question regarding the qn908x nor flash driver and the common CRC32 function: I split this into two commits, the first moving the OR1K CRC32 function out to crc32.c as a generic crc32_le() function and updates the OR1K code to use that. The second commit adds the QN908x flash driver that also makes use of the same generic crc32_le() function. What's the best way to proceed?

19:15 <maribu[m]> Should I open a new change with the CRC32 commit, wait for it to get upstream, then update the QN908x change?

19:16 <Hawk777> Gerrit allows you to make changes be related to each other in a dependency order. I’m not certain *exactly* how you do it, but it is possible.

19:16 <Hawk777> I’ve seen multiple Gerrit changes that correspond to Git commits built on top of each other, and Gerrit shows the stack of related changes somewhere.

19:27 <maribu[m]> Let's see what happens when I just push the two commit of my branch. Maybe Gerrit automagically makes the later commits depend on the earlier ones?

19:31 <Deneb> I just received the OLIMEX ARM-USB-OCD-H adapter I oreder to use with openocd. I have just reviewed the manual and it mentions it works with targets powered at between 1.65V and 5V but can't find anywhere where it says how to set the target voltage?

19:32 <Hawk777> I’m not sure, but you might not need to?

19:33 <Deneb> Hawk777: thanks, but how so? Does it automatically detect the targets logic level somehow?

19:33 <Hawk777> Normally JTAG adapters are powered *by* the target, they don’t power it, so if the target feeds e.g. 3.3 into the adapter’s VDD, it probably uses that to power I/O buffers and then feeds signals back at 3.3.

19:34 <Hawk777> There are some exceptions to the rule (i.e. adapters that can power the target), but normally VDD is an output from the target and an input on the adapter.

19:34 <Deneb> ah, I wonder then, if I need to feed the target VDD into the adapter VREF?

19:34 <Hawk777> Maybe it’s called VREF? I don’t know the naming of the pins on that particular adapter.

19:34 <Hawk777> Sounds likely.

19:35 <Hawk777> But I’d see if the manual explains the purpose of each pin just to be certain.

19:37 <maribu[m]> I think that Gerrit did just automagically assume that the second commit depends on the first and translated this into a "relation chain" :)

19:39 <Deneb> Hawk777: there's a TARGET_POWER, but that is described as 'TARGET SUPPLY' and an earlier description says it provides 5V to the target. Unfortunately I see no descripton of VREF.

19:40 <Hawk777> Well, don’t hold me responsible for damage, but my *guess* would be you bring the target’s VDD into the adapter there.

19:41 <Deneb> Hawk777: well, that is kind of my point. I would rather be sure. There is a forum on the Olimex website so I might post a quedstion there before trying to use it. Thanks for answering.

19:41 <Hawk777> Might be wise, yeah.

19:41 <Hawk777> Or see if anyone else has explained the purpose of that pin somewhere on the web.

19:42 <Deneb> I thought there might be a parameter in the cfg file but I had a look and there is nothing relating to voltage. Will research further before connecting to anything.

20:00 <PaulFertser> Deneb: pin 1 of JTAG connector is connected to target's Vcc.

20:00 <PaulFertser> Deneb: Vtref or something it's called usually.

20:00 <PaulFertser> Deneb: that's how you set the voltage for the output buffer.

20:01 <borneoa_> maribu[m]: the two patches are pushed correctly in the proper order. Thanks. I'm not sure I would be able to review them before a couple of days

20:03 <PaulFertser> Deneb: Olimex has a good user manual, it explains you can get 5 V (I guess it's just USB Vbus) from the barrel socket connector.

20:04 <maribu[m]> No problem :) I am well aware that maintainer duties can take time, especially when being multiplexed with other work duties and private life ;)

20:05 <PaulFertser> maribu[m]: I wasn't automagic. Every git commit has a hash of its parent(s).

20:06 <PaulFertser> You're pushing a git ref so naturally the order is preserved because the gerrit changes are still Git commits.

20:07 <PaulFertser> If use e.g. git rebase -i on your local tree to reorder commits you'll be in fact creating new different commits, and when you push those, the relationship of Gerrit changes will change too.

20:16 <Deneb> PaulFertser: yes, it does explain that the 'H' version can provide only 5V to the target. It is also explicit in stating that the connector is not a DC input!

20:17 <PaulFertser> Deneb: I used ARM-USB-OCD-H at work for years, it's quite nice, sturdy enough adapter.

20:17 <Deneb> PaulFertser: I was however trying to understand how the logic levels are set. I suspected the VREF might be the answer and you seemed to have confirmed that is likely. I can't see that explained in the manual though.

20:19 <Deneb> it seems they have a newer one - HL variant - which operates down to 0.65v.

20:20 <Deneb> I didn't realise that I would need a separate adapter fr SWD, but at least they are not expensive

20:21 <PaulFertser> Deneb: the manual says that Vref should be connected to target's Vcc. And that if the adapter sees Vref is zero, it'll put out 5 V on pin 19 automaticallyy.

20:21 <Deneb> newer version has usb-c instead of usb-b which much more sturdy

20:26 <Deneb> yes, I saw that bit "Pins 1 and 2 of the JTAG connector are voltage reference that probes if the target is already powered by another source.". Wasn't sure how to understand that as it doesn't specifically state that it sets the logic levels but I guess that would make sense.

20:28 <Deneb> thanks for the clarification

20:39 <PaulFertser> :)