07:26 <maribu[m]> Regarding the flash driver for the QN908x MCUs (https://review.openocd.org/c/openocd/+/5584/): I just installed a fresh build with that patch applied to the current master, and verify_image there fails while it does work in the branch I'm developing the flash driver. So please don't merge that right now, I'd like to have this working robust first.

07:29 <maribu[m]> Flashing does work fine in both versions. There are some things that I cannot explain in the behavior, though.

07:41 <PaulFertser> maribu[m]: hey

07:42 <PaulFertser> maribu[m]: comments like that should better be added to Gerrit, you can put your -1 along the way.

07:42 <PaulFertser> maribu[m]: thank you for working on that driver!

07:43 <PaulFertser> maribu[m]: CI says it doesn't compile anyway, so don't worry, it can't be merged :)

07:47 <maribu[m]> Oh, man. That build failure just found I pretty serious bug :)

07:52 <maribu[m]> One question: I get a `Warn : no flash bank found for address 0x20000000` warning after rebasing on `master`. This makes sense, as this is where SRAM is located. However, the TCL script uses `$TARGETNAME configure -work-area-phys 0x04000000 -work-area-size $WORKAREASIZE`. According to the data sheet 0x04000000 is the "canonical" address where the SRAM is mapped, but 0x20000000 is an euqally valid alias region for the SRAM. (Note: It is not a

07:52 <maribu[m]> bit-banding alias, but it really works just the same.)

07:52 <maribu[m]> So, I kind of have to expect that ELF files may use either SRAM address range, as both are equally valid. Is there a way to configure that correctly in TCL?

07:54 <PaulFertser> maribu[m]: your elf file should not have any sections with load address 0x20000000 I think?

07:55 <PaulFertser> maribu[m]: it looks like somehow your LD script puts something in the elf that makes OpenOCD think that 0x20000000 needs to be flashed too.

08:02 <PaulFertser> (my terminology might be off but I hope you get the idea)

08:05 <maribu[m]> Could be. So -work-area-phys mismatching the SRAM address range the firmware uses (which, given that there are two equally valid areas is a 50:50 chance) is not the issue here?

08:06 <maribu[m]> [ 5] .stack NOBITS 20000000 005000 000200 00 WA 0 0 1 is one of the segments in question, the others have the same flags.

08:06 <maribu[m]> Let me double check if I don't get the warning when flashing STM32 boards as well, and it is a systematic issues in RIOT's linker scripts.

08:09 <PaulFertser> maribu[m]: yeah, OpenOCD doesn't care about how ELF is going to use RAM at all. work-area can be configured to use any place in it.

08:12 <PaulFertser> maribu[m]: if certain section should be in RAM during the run time in the ld script it should be specified like this: .data : AT (_flash_data) (that is, AT keyword should be used to set the flash location for it)

08:15 <PaulFertser> maribu[m]: OpenOCD only uses PT_LOAD segments for flashing.

08:17 <maribu[m]> The current git version of OpenOCD won't flash the ELF files for STM32 boards as well. I will investigate what the issue is.

08:18 <PaulFertser> maribu[m]: objdump -h <yourelf> | grep -B 1 LOAD

08:22 <maribu[m]> That looks fine, nothing in the SRAM region is marked as LOAD

08:38 <PaulFertser> maribu[m]: probably 047b1a8fc237af480e3bab66a9827a358afd7547 is related, there were no other changes to src/target/image.c lately.

08:40 <PaulFertser> Might have been tested only for loading ELFs to RAM.

08:40 <PaulFertser> Looks like it might indeed affect flashing.

08:51 <PaulFertser> Yep. If reverting it fixes everything you just add a comment there on Gerrit and Antonio and the original author will do the right thing to revert or to fix it.

08:54 <PaulFertser> maribu[m]: sorry about that. Regressions happen, any progress would be impossible otherwise.

09:02 <maribu[m]> No problem. My initial assumption was that the regression is actually due to a bug in my code not triggered so far.

09:06 <PaulFertser> maribu[m]: easy to check by reverting that commit

09:10 <PaulFertser> maribu[m]: or by converting to .hex file and flashing and verifying that instead.

10:13 <maribu[m]> Indeed, with the revert it works all as expected :) (Except for the bug the CI found; but that was easy to fix.)

10:30 <Deneb> is there an irc channel that deals specifically with baremetal? I would like to find a definitive answer on whether there is a way to determine whether a device implements SWDv1 vs SWDv2 and whether SWDv2 is backward compatiblwe with SWDv1?

11:34 <PaulFertser> Deneb: hi

11:35 <PaulFertser> Deneb: if you have multi-drop SWD in mind, then yes, they're all compatible. Of course a non-multi drop device can't share a bus with any other.

11:42 <PaulFertser> Deneb: I think if the vendor doesn't state SWD DPv2 in the datasheet then you can't count on it being available.

12:21 <Deneb> PaulFertser: thanks. That makes sense.

12:24 <PaulFertser> Deneb: or were you asking about debug adapters, not targets?

12:25 <Deneb> PaulFertser: but you have also clarified the point with mixing v1 and v2 devices on the same bus. Haven't done anything with multidrop yet, but did wonder about that.

12:25 <Deneb> PaulFertser: asking about targets.

12:25 <PaulFertser> Because for adapters if it's not a high-level then OpenOCD will support multidrop on old adapters too.