<zapb_>
I'm wondering why there is no ready-to-use config file for it
<zapb_>
(I never used FTDI chips as debug probe)
<Hammdist>
thanks.my board has the reset on ADBUS4. any hint on how to adjust that config? [probably the answer to that is there are different ways to wire the busses on the ft232h boards]
<Hammdist>
first of all I assume TRST SRST (or at least SRST) are important right?
<Hammdist>
even with "explanatory comments" in the file I'm very confused how it works
<zapb_>
Hammdist, depends on your board. my blue pill board has only SWD
<Hammdist>
usually the extra pin(s) required for JTAG are broken out anyways. so one can JTAG it but the pin names aren't on the silkscreen as JTAG
<Hammdist>
my main concern now is how to update that example file so that nSRST is on ADBUS4, not ACBUS1
<zapb_>
Hammdist, did you check the manual for the FTDI driver?
<Hammdist>
I think I finally understood what the bits in the file are doing
<Hammdist>
I should be able to adapt it now
<borneoa___>
Hammdist: the firmware already in the stm32 can reprogram the JTAG pins. If you fail to connect, try to keep the stm32 under reset
<PaulFertser>
There is a config file for ftdi breakout board.
<PaulFertser>
E.g. ft232h-module-swd.cfg , works as jtag too.
<PaulFertser>
And it has reset on ADBUS4, just like you want Hammdist.
Haohmaru has quit [Read error: Connection reset by peer]
Haohmaru has joined #openocd
<PaulFertser>
Hammdist: please use some pastebin to show what you're getting there.
<Hammdist>
borneoa___: I thought the reset is always asserted when connecting by JTAG to kill the currently running program and tristate all the user pins
<PaulFertser>
Hammdist: it's not, often times you want to connect to a target for inspection.
<PaulFertser>
Imagine a device hangs once a day
<Hammdist>
ah so I must add a reset to my programming script to be sure
<PaulFertser>
Hammdist: just use "reset_config connect_assert_srst" to be sure, yes.
<Hammdist>
it could be the default bootloader isn't designed for JTAG
<Hammdist>
ok will do
<PaulFertser>
Hammdist: some bluepills might have different IDCODE and would show an error with target/stm32f1x.cfg
<PaulFertser>
Hammdist: the default bootloader on F1 is designed for UART. And while it's running JTAG and SWD work fine too.
<PaulFertser>
(I'm talking about the one and only bootloader that is in ROM)
<zapb_>
PaulFertser, the config named '-swd' works with jtag too?
<PaulFertser>
zapb_: oh heh it has "transport select swd" in the middle. Silly.
<Hammdist>
yes but blue pill manufacturer can put secondary bootloader that doesn't care about JTAG and then one is stuck (without the reset assert)
<PaulFertser>
zapb_: good point, um232h.cfg is more suitable then.
<PaulFertser>
But SRST needs to be remapped the way ft232h-module-swd.cfg does
<Hammdist>
I don't have access to the stm32 board at the moment
<PaulFertser>
Hammdist: either that or BOOT jumper can be used, yes.
<Hammdist>
but will check back tomorrow
<PaulFertser>
"at this stage I have all the hardware together"
<Hammdist>
that was a few hours back :)
<PaulFertser>
If you just want to program and run why not program via UART?
<Hammdist>
goal is to qualify my ft232h circuit actually I have little interest in blue pill itself
<PaulFertser>
Hammdist: some targets do not like bare FTDI chips talking to them, all the proper JTAG adapters have buffers (for voltage matching) and series termination resistors.
<Hammdist>
voltage always 3.3v ; distances relatively short (hopefully will be OK)
<Hammdist>
plus most issues go away if you set the megahurts low enough :)
<PaulFertser>
Hammdist: the problem is not the distance but "ringing" when you connect a CMOS output to a high-Z CMOS input without any kind of line termination. Even 5 cm cable might be enough to get it.
<Hammdist>
well I will consider termination resistors then
<PaulFertser>
Ringing doesn't depend on interface frequency because it occurs on _every_ edge.
<PaulFertser>
Having like 47 Ohm in series on every data line never hurts.
<PaulFertser>
Hammdist: btw, are you going to use this to talk to some FPGA? Then you do not need to care about SRST.
<Hammdist>
I thought ringing depends on interface speed, as the ring is far from the sampling window when the clock is slow
<PaulFertser>
Hammdist: right but what if you get ringing on the clock line itself?
<Hammdist>
dunno but I would imagine the clock line itself is made robust by being a schmitt trigger or something like that
<PaulFertser>
Indeed that kinda helps but depends on how "loud" the ringing is. Fact is, tried and trusted JTAG adapters have line termination.
<Hammdist>
well I will add those 47ohms to my design then :)
<PaulFertser>
:)
Jos has joined #openocd
Jos is now known as JoseT
<NishanthMenon>
quick question: on one of our chips, we have a APreg based scheme to access flash - and this is needed before CPU can be accessed (some sort of security configuration writes) - have anyone seen a dap register based flash drivers before? looking for some sort of reference driver
Haohmaru has quit [Quit: saionara]
_whitelogger has joined #openocd
<zapb_>
NishanthMenon, IIRC EFM32 series 1 devices, e.g. EFM32GG, have such a security mechanism
<zapb_>
However, it is not directly supported by OpenOCD AFAIK
nerozero has quit [Ping timeout: 255 seconds]
<zapb_>
NishanthMenon, NXP Kinetis may have support of such a feature
<NishanthMenon>
zapb_: aah ok thanks.. we do have a forked story for https://www.ti.com/lit/pdf/swcu193 -> CC2340R5 - trying to do it clean and get support in upstream
<NishanthMenon>
JoseT: ^^
<zapb_>
NishanthMenon, maybe you can use mem-ap before using the actual target?
<zapb_>
s/mem-ap/mem-ap target
<NishanthMenon>
Yeah, sec-ap is what JoseT needs to use. Apparently we have a ROM flash driver that does the writing and stuff
<NishanthMenon>
He does have a functional driver now.. just was curious why he didn't see other drivers of the form..
<zapb_>
NishanthMenon, nice, I really like to see that TI works on upstream device support
<zapb_>
NishanthMenon, your MSPM0 driver is on my TODO list jyfi