11:43 <Guest23> hi there!

11:43 <Guest23> I've a question regarding openocd ftdi configuration options

11:44 <Guest23> I have a swd target and tries to hook up an ft2232 based board to it

11:45 <Guest23> looking at the signal with an oscilloscope it seems that when the target answers to the IDCODE request

11:46 <Guest23> it has some problems raising the voltage to 3v3 (~2V5)

11:46 <Guest23> so I assumed that my board is also trying to drive the line at this moment

11:46 <Haohmaru> do you have pull up resistors on the SWD signals?

11:46 <Guest23> I do yes

11:47 <Guest23> I tried 470 and 220 as recommended by arm

11:47 <Guest23> ah, no I misunderstood your question

11:47 <Haohmaru> because, iirc, in the SWD transactions, when the direction changes (on SWDIO signal particularly) you have to have a pull-up resistor

11:47 <Guest23> I didn't had a pull-up resistor

11:48 <Haohmaru> there's an intentional time gap while the SWDIO direction changes, where neither the debugger nor the target would drive that signal, so it'll float

11:48 <Haohmaru> thus they require a pull-up resistor

11:48 <Guest23> from what I've read it should be one clock tick

11:48 <Haohmaru> if you don't have it - maybe that's what you saw on the oscilloscope

11:48 <Haohmaru> but this is just a speculation

11:49 <Guest23> maybe, but I guess it would last just for the direction change

11:49 <Guest23> this occurs for every time the target wants to drive the line to 3V3

11:50 <Haohmaru> not being able to get to 3.3V on that signal could be caused by something else too

11:50 <Guest23> yes that's what I was wondering

11:50 <Haohmaru> like, a (semi)short with another thing

11:51 <Guest23> I doubt the semi short as it occurs on each samples

11:51 <Haohmaru> you could try powering off the thing and measure resistance from SWDIO to GND and to 3.3V and to neighbour pins or other suspicious places

11:51 <Guest23> I was thinking of ftdi configuration, as I have troubles understanding the SWD_EN and SWDIO_OE options

11:52 <Guest23> ok I'll try that

11:52 <Guest23> thx

11:52 <Haohmaru> no clue but based on the name SWDIO_OE probably means OutputEnable

11:52 <Guest23> that's what I thought yes, so I've set it to 0 so that there wouldn't be any conflicts on the line

11:53 <Haohmaru> this is the signal that changes direction, so when you want to output you'd Enable the Output of it, otherwise disable it (the output driver would go to hi-Z) and then you can use the signal as input

11:53 <Haohmaru> well, no idea about this in the context of the ftdi

11:53 <Haohmaru> wait for some of the others to wake up

11:53 <Guest23> same here and the documentation isn't very clear from me haha

11:53 <Guest23> sure, thx!

11:53 <Haohmaru> i've only used daplink-based debuggers

11:58 <Guest23> also what is strange is that I tried using the jtagulator to verify if it works and it can find the IDR

11:58 <Haohmaru> is that another debugger?

12:00 <Guest23> no it's a device to bruteforce swd/jtag pins

12:04 <Haohmaru> so it works with that one

12:05 <Haohmaru> to some degree at least

12:06 <Haohmaru> did you also check that it's not something silly like the whole 3.3V line (or at least the VDD of the target) happen to have gone down to 2.5V?

12:06 <Haohmaru> because then seeing 2.5V when it drives SWDIO would be unsurprising