07:43 <PlasmaHH> Hi, trying to wrap my head around how to properly wire an ft2232 into my board to make proper use of swd and reset signals. its a bit confusing at times since the docs mostly talk about jtag and its signals. so the cortex-m swd adapters only have srst for reset, so is it possible to nevertheless use trst and wire it as a "master reset" thing?

07:43 <PlasmaHH> despite the usual jtag description saying its only for the tap controllers? or would that not be wise as openocd could use that on its own? the goal is to have a way to control that master reset thing via a monitor command in gdb

07:45 <PaulFertser> PlasmaHH: hi!

07:46 <PaulFertser> PlasmaHH: no, TRST is JTAG-specific signal, do not connect it at all in case you have SWD only.

07:46 <PaulFertser> PlasmaHH: use SRST for "master reset", that's exactly the meaning of System ReSeT

07:47 <PaulFertser> PlasmaHH: if your target is 3.3 V you can connect FTDI's TDO and TDI directly together and feed that to SWDIO.

07:47 <PlasmaHH> PaulFertser: usually I connect it to the mcus reset pin to only reset that chip and I would like to have the ability to do both independently

07:47 <PlasmaHH> yeah its 3.3v and directly connected

07:48 <PaulFertser> PlasmaHH: that would suggest improper design. The target MCU reset should be connected to all other reset in parallel so that every time the board is reset by whatever means it starts from a known state.

07:49 <PaulFertser> To facilitate that the MCU even _emits_ a reset pulse on its own when reset is triggered internally by watchdog.

07:50 <PaulFertser> I mean if you really know why you need a separate signal, sure, use one and specify in your adapter config but I'd recommend to use a proper descriptive name rather than confusing (in this case) nTRTS.

07:51 <PlasmaHH> PaulFertser: yeah I understand that thats normally the case but I have some other hardware there that has latched states (not solely controlled by that mcu either) that need a power cycling for "full reset". plus to get out of some states I want to have that power cycle ability for the mcu too

07:53 <PaulFertser> PlasmaHH: again, if you clearly see all the consequences, sure. But I prefer it simple so it's more predictable. E.g. if I know some IC has reset pin but that reset doesn't properly fully reset it probably I'd leave it permanently pulled up and that's it. If I can't count on it doing reliably what I need then probably I should ignore it altogether.

07:53 <PlasmaHH> ok yeah another name sounds fine as long as I can access it via a monitor command

07:53 <PaulFertser> You can, sure, it would be an ftdi-specific command though.

07:54 <PaulFertser> "ftdi set_signal"

07:54 <PlasmaHH> acccessible via gdbs monitor command and not just tcl config?

07:54 <PaulFertser> It's not possible to have a Tcl command not accessible by gdb monitor command.

07:55 <PaulFertser> Because gdb monitor is handled by the Tcl interpreter.

07:55 <PlasmaHH> the problem with that "ignore it altogether" thing is if its the mcu that does not fully reset in call conditions on the reset signal ;)

07:55 <PlasmaHH> ah good to know, will try to keep that in mind ^^

07:56 <PaulFertser> Probably the most reliable approach then would be to integrate a power-cycling circuity on the board itself and to allow it to be triggered from SRST so that MCU watchdog could reliably cycle the whole board.

07:57 <PaulFertser> You're building your own board anyway and MOSFETs are cheap these days.

07:57 <PlasmaHH> yeah no, with those other chips that I want to keep their state normally thats not the best idea...

07:58 <PlasmaHH> I have that circuitry set already but the question is about who controls it and more explicitly is better, I don't want stuff to start moving when the mcu is reset

07:59 <PlasmaHH> its not the only mcu on that board too..

07:59 <PaulFertser> One thing is if you need to keep the state another is that you want to do it. Because if not really needed sometimes after considering the failure scenarios you might see you do not want it after all :)

07:59 <gamiee> ftdi set_signal is paaaaain to use

08:00 <PaulFertser> PlasmaHH: you have many pins on that ft2232h , can do pretty fine-grained control if needed, yes

08:00 <PaulFertser> gamiee: oh why?

08:01 <PlasmaHH> PaulFertser: hm, true that, I could even seperately control the mcu power only, which is the most likely reason I need that anyways to reset it

08:05 <gamiee> PaulFertser : finding documentation to the FTDI GPIO configuration is very hard. I remember when I was doing this configuration it took me quite a time to figure it out

08:05 <gamiee> i should have write some docs about it and add it to openocd the last time I was working on it, damn

08:08 <PlasmaHH> I didnt look into it for a while, but wasnt it relatively straightforward? you could name a signal and configure a mask or so for it and then just use that name for set/get ?

08:08 <PaulFertser> gamiee: I'm surprised to hear that

08:09 <PaulFertser> What PlasmaHH says

08:10 <PlasmaHH> I wish their 4232 would support swd for all channels..

08:45 <gamiee> PlasmaHH : but did you found the bitfields docs easily?

08:46 <PlasmaHH> gamiee: can't remember really, is it more complicated than a 1:1 relationship between the bits and the gpio ports?

08:47 <gamiee> PlasmaHH : afaik it wasn't that simple, but maybe I am thinking of something else? :D

08:47 <PlasmaHH> dunno, its been too long ago that I looked at those to remember...

08:48 <PlasmaHH> which could mean yesterday in some circumstances :P

09:16 <PaulFertser> gamiee: it's straightforward mapping

09:17 <gamiee> ummm, then i am confused :D

09:44 <PlasmaHH> so are we

09:46 <Haohmaru> this is the world we live in (oh-ooh-oh) and these are the hands we're given..

10:09 <PlasmaHH> found one from the early 90s...

10:17 <PlasmaHH> hm, it ran away on its own... don't really feel climbing behind my parts cupboard...

10:17 <Haohmaru> what kind of a fish is that o_O

10:17 <PlasmaHH> sitting more than 30 years in the basement, probably some evolution happened

10:18 <Haohmaru> i'm starting to get worried about your basement

10:18 <PlasmaHH> note to self: don't store expired food near radioactive waste

10:18 <PlasmaHH> Haohmaru: wait what why?

10:25 <Haohmaru> because there's too many men, too many people, making too many prob-lems...

10:34 <PlasmaHH> calculating cluster trout launch trajectory...

10:37 <Xogium> Haohmaru: ref to disturbed ? ;)

10:38 <Haohmaru> well, the original, but disturbed's version is very nice too

10:39 <PlasmaHH> Haohmaru: should you in the next days outside feel a sensation like rain is stinging... its nothing to worry about

10:39 <Xogium> ;)

10:44 <Xogium> great now I'm stuck with the song in my head hahaha

10:44 <Haohmaru> >:)

10:46 <Haohmaru> this is the "noise floor"

10:47 <Xogium> I remember when I had chemo and radio treatments... One side effect was that apparently I was much more likely to end up with parts of songs on repeat

10:47 <Xogium> it didn't miss. I spent literally 2 weeks with parts of the ring of fire in my head. I thought I'd go mad

10:48 <Haohmaru> que

10:49 <Haohmaru> actually, it's not always a song, it might be just some track without vocals

10:49 <Xogium> yeah that happens too

10:50 <Xogium> guess that is what happens when one has always music in the background :D

10:50 <Haohmaru> i don't

10:51 <Xogium> I always do have some sort of music in the background. I don't know why that is, but it seems to keep the brain from panicking at the silence

10:51 <Haohmaru> here i'm listening to the outside traffic and a bunch of f*cking pseudo-seaguls barking from time to time