17:04 <CSpegal> We have a board/chip that has active high jtag trst/srst so I'm looking to implement that option. I've already edited src/jtag/adapter.c to include the options trst_inverted and srst_inverted. I also added the necessary bits to the reset_types enum. I'm wondering if you think this change is best to implement at the driver level or in the core. The

17:04 <CSpegal> problem with doing it in the core is some drivers have hard coded reset routines in the init for options RESET_CNCT_UNDER_SRST and RESET_SRST_NO_GATING.

17:09 <PaulFertser> CSpegal: hi. Must be some quite an unusual chip.

17:10 <PaulFertser> CSpegal: some interface adapters can't even drive SRST high, the usual way is to use open drain to handle it.

17:10 <CSpegal> It is, it's a custom SoC.

17:10 <PaulFertser> CSpegal: and with TRST, does it mean you can't use other JTAG devices in the same chain if you're using TRST?

17:11 <PaulFertser> CSpegal: isn't it better to add a custom inverter on board for the custom SoC for those signals? And fix the SoC in the next iteration.

17:12 <PaulFertser> CSpegal: I'm just wondering if your case is so special that the best way would be for you to have a custom temporary hack instead of trying to provide a generic solution.

17:12 <CSpegal> We did that on the second rev of the board. Working on testing the first rev now.

17:13 <PaulFertser> CSpegal: and TRST isn't really needed for JTAG.

17:14 <PaulFertser> If it's just for testing an early rev why bother with trying to upstream such an unusual quirk?

17:14 <CSpegal> It probably is a very special situation. And considering the the OD issue you pointed out probably not worth a generic solution.

17:15 <PaulFertser> CSpegal: if you have DP Busblaster adapter you can load custom CPLD config into it for inverting.

17:16 <PaulFertser> CSpegal: so what debug adapters do you have?

17:18 <CSpegal> We were using a ft2232 and recently tired it with a cmsis-dap (Atmel ICE). The ICE is nice because the board has an ARM standard header for the JTAG interface.

17:18 <CSpegal> The ft2232 board they were using required a breadboard mess.

17:20 <CSpegal> I figure I could just hack the driver for cmsis-dap to invert it but decided to go over kill and look at a generic solution.

17:20 <CSpegal> Also the board assumed the resets were active low too so they are pulled up.

17:21 <PaulFertser> CSpegal: not to demotivate you, but I'm not sure it's going to be useful to anybody else.

17:21 <PaulFertser> CSpegal: btw, using bare ft2232 might prove problematic signals-integrity wise, usually jtag adapters include series resistor for source termination.

17:26 <CSpegal> No, not at all. Honestly I appreciate you pointing out that this is a special case that probably won't be useful to anyone else.

17:26 <CSpegal> Not worth the effort for a generic solution then.

17:29 <CSpegal> PaulFertser They were using a FT2232H Mini Module and were having trouble with is between the boardboard and level shifter they needed to use with it to connect to the chip.

17:30 <PaulFertser> CSpegal: I see. Then the termination needs to be after level shifter, between it and target.

17:38 <CSpegal> PaulFertser I doubt they had those. Probably something to look into. They also removed the pull-ups on the board because they caused problems they said. I wonder if lack of series termination had to do with that.

17:50 <PaulFertser> CSpegal: assuming they're EEs they'd check signal shapes near the SoC and would see "ringing" and would implement termination if that was a problem.

18:28 <CSpegal> They're test engineers, not really used to circuit design, but I'll have to ask them. I designed the board with the standard JTAG termination but didn't get involved with the adapter configuration until they started having problems. I was also not told the resets were active high during the design process.

18:30 <PaulFertser> CSpegal: btw, there's a board called TUMPA, it has a nice fast buffer IC and also it push-pulls reset.

19:25 <CSpegal> I'll look into it. Thanks for the help!