07:55 <gamiee> Hmm, this is strange. I have JLink connected to the target. When I use JLink server, it probes the chip just fine (Cortex M33). But when I use OpenOCD, it manages to get DPIDR (which is right), but afterwards, Examination failed, with often different error message, which looks like signal integrity issue? But why same connection, same JLink works just good with JLInk Server....

07:56 <gamiee> (what is even more strange, when using FTDI with SWD resistor hack, it's also not always stable, but it's capable of examination of the chip properly and also debug the target... with same TCL config... I am super confused)

07:59 <zapb__> gamiee, what target is it? There should be no difference between OpenOCD and JLink server wrt signal integrity etc.

08:01 <gamiee> zapb__ : hi! Sorry, I can't disclose yet, but anyway, there are absolutely 0 information online about the chip. Just it uses ARM Cortex M33 core, made by ARM China.

08:01 <gamiee> and exactly, it does not give any sense :/

08:02 <PaulFertser> Probably the adapter speed is different?

08:03 <PaulFertser> Fastest way would be to check the signals with oscilloscope.

08:07 <zapb__> Well yes, maybe the default speed is different

08:59 <gamiee> PaulFertser: actually, on JLink Server, it was 4000 Hz, on OpenOCD only 200 Hz. But I tried 4000 Hz on OpenOCD as well, but that did not helped as well.

08:59 <gamiee> So yeah, even on slower speed than JLink Server, it did not worked. That's why I am super confused. And yeah, I plan to check it out on logic analyzer.

09:31 <Haohmaru> are you sure that's Hz and not kHz?

09:31 <Haohmaru> 200Hz is like a high-pitch fart

10:40 <gamiee> Haohmaru oops... Yeah, brainfart. I guess every number I used/told is kHz, sorry

12:59 <gamiee> this is debug log from openocd btw: https://paste.debian.net/1349968/

13:07 <Haohmaru> mmm, error code -4, that old -4

13:08 <Haohmaru> CPUID 0x0?

13:12 <gamiee> yeah, 0x0, I don't get why

13:13 <Haohmaru> is this over SWD or JTAG?

13:14 <gamiee> SWD

13:14 <gamiee> And JLink

13:15 <Haohmaru> and, you say with jlink alone (this thing makes a gdb server itself, thus no openocd involved) it "works" (so this CPUID is nonzero), but when openocd pulls the ropes of the jlink you get the above ^

13:15 <gamiee> exactly

13:16 <gamiee> This is from JLink (Server): https://paste.debian.net/1349974/

13:16 <Haohmaru> if the jlink doesn't do anything different in general with the actual SWD (like different pin drive strength, or pull resistors, something of this sort), then i'd think a possible difference could be related to timing

13:17 <gamiee> Exactly, that's why I do not get it :/

13:17 <Haohmaru> speed and/or the time between different SWD "packets"

13:17 <gamiee> but even it does not scan all AHB-APs

13:18 <Haohmaru> other possible thing could be the actual sequence of SWD commands (the algorithm of the communication) could differ between jlink alone and openocd->jlink

13:19 <Haohmaru> iirc SWDIO generally should be pulled... up i think

13:19 <Haohmaru> when the SWDIO changes directions there are moments when neither side shall drive it and then it is left to the pull resistor

13:21 <Haohmaru> wait a minute... "AP[0]: Skipped. Invalid implementer code read from CPUIDVal[31:24] = 0x00"

13:21 <Haohmaru> isn't that the same CPUID?

13:21 <Haohmaru> is your mystery MCU a legit one or is it some very early alpha version ;P~

13:22 <Haohmaru> if you scan it with a very fancy X-RAY microscope, are there a lot of "/* TODO */" inbetween the transistors ;P~

13:23 <gamiee> Ohh, nice catch from JLink log. Ummm, well , I do not know :D :D :D (to other side, this is dual core MCU) it's mystery for me as well. (I even don't have the chip, I am doing stuff remotely)

13:23 <Haohmaru> like "/* TODO: this should return a CPUID that we haven't registered yet, so for now we return zeros */"

13:24 <Haohmaru> because to my nose it seems openocd just quits further operations when CPUID turns out to be 0x0 and it doesn't recognize wtf this is

13:26 <Haohmaru> not sure if the list of known "CPUID" values is something hardcoded into openocd, or whether you can override it (or specify a custom CPUID value) in a config, but if it's possible you could try fooling openocd that 0x0 _is_ the "right" value for this MCU and then maybe openocd would continue forward with the operations

13:26 <gamiee> Bingo!

13:26 <gamiee> I need to specify -ap-num to "1"

13:27 <Haohmaru> mmm, the name of this is familiar but i forgot what it was for

13:27 <gamiee> CPUID is specified in OpenOCD

13:27 <gamiee> there are known vendors of ARM cores. This one is from ARM China

13:29 <Haohmaru> yeah i'm almost sure openocd probably might have a map/LUT of a bunch of basic CPUIDs, but i would maybe thing this could be overridden either via commands or configs

13:30 <Haohmaru> e.g. you can tell avrdude to ignore the "deviceID" of a chip and continue with the commands

13:30 <Haohmaru> this can happen if something is not quite right but it could still work as long as avrdude pretends that things are okay

13:34 <gamiee> heh

13:34 <gamiee> now it makes sense

13:34 <gamiee> for some reason, CPU0 is halted, so I can't access it, that's why AP0 is having CPUID 0x0

13:34 <Haohmaru> oh

13:35 <Haohmaru> the two cores have individual debug stuff that work independantly?

13:35 <Haohmaru> or well, i wouldn't understand it even if someone tells me, ignore this question

13:35 <Haohmaru> if the problem is solved - good ;P~

13:36 <gamiee> I do not know how this exactly works either. But yeah.

13:38 <gamiee> So basically, JLink worked only because it automatically switched to next AP

13:39 <gamiee> Haohmaru : thank you for rubberduck debugging, I appreciate it.

13:40 <Haohmaru> kool

14:41 <karlp> gamiee: I remember adding a part number for some arm china stuff before, there might be more to add.

14:43 <karlp> yeah, src/target/arm.h, arm_implementer

14:43 <karlp> PaulFertser: did we turn off gitweb on gerrit? was there meant to be some other path to browse source?

14:43 <karlp> meh, back to openocd.org to source forge is ok I guess.

14:48 <Haohmaru> is the vendor literally called "ARM China" o_O

14:58 <karlp> that's.... their name?

14:58 <karlp> did you miss the whole arm vs arm china shit?

15:00 <Haohmaru> when, where?

15:00 <Haohmaru> i guess "yes"

15:12 <gamiee> karlp : No need, it was identified properly it's just STAR-MC1

15:58 <PaulFertser> karlp: yes, gitweb was contributing to Gerrit being slow sometimes.

15:59 <karlp> np, just couldn't figure out what I was missing :)

22:33 <antto> does anyone happen to know how to build a firmware for a daplink?

22:34 <antto> i was trying to see if i can rebuild the firmware for this kamami zl33prg, which i *think* is very similar to SWDAP or DIPDAP (it uses lpc11u35 and has SWD and UART)

22:35 <antto> i followed the build instructions, got entangled in snek scripts, and uhm, i tried building "lpc11u35_if", a firmware .bin was generated, but i have no idea if this is the right thing or not

22:36 <antto> when searching for "lpc11u35" there are too many results all over the daplink projects (many in those yaml files and i can't figure out wtf's going on)