10:17 <Battosai42> Hi Everyone, i hope this is the right place for a question.. I have openocd 0.12.0rc2 running  using an FT C232HM chip. My issue is that between every transaction JTAG remains in the RUN/IDLE state for around 30ms before the next interaction. i am trying to reduce this time in order of speeding up as currently this RUN/IDLE state is more that 99%

10:17 <Battosai42> of the entire time (even for a low adapter speed setting) for no apparent reason.. so far i could not find any reason for this or how i could configure this RUN/IDLE wait time.. any hint or help would be much appreciated!

10:46 <PaulFertser> Battosai42: hi

10:47 <PaulFertser> Battosai42: what are you doing with that adapter exactly?

10:47 <PaulFertser> Battosai42: the driver is known to do the right, efficient thing during batch memory transfers.

10:50 <Battosai42> its entirely possible i am doing something wrong (i am fairly new to openocd). all it do is set up 2 TAPs, one of which is a DAP declared as such. the target is an ARM M3 but since i dont need GDB i have not declared the target, only the DAP and TAP is declared

10:51 <Battosai42> i can talk to either DAP/TAP just fine, only this very long pause in the RUN/IDLE state is bugging me as i dont understand why its there

10:52 <Battosai42> ah, i am only using ir/drscan interactions and no bulk transfer specifically.. could that be related?

10:55 <PaulFertser> Battosai42: irscan/drscan interactions by default end up in RUN/IDLE, yes.

10:56 <PaulFertser> Battosai42: why are you using those low level operatioons if you have M3 which is supported by OpenOCD already on target level?

10:57 <PaulFertser> Battosai42: even if you do not need GDB you should probably still define the target and use OpenOCD commands for targets (reg, resume, bp etc.)

10:57 <PaulFertser> mdw, mww

10:57 <Battosai42> i did try using apreg/dpreg to access the DAP, but could not get that to work properly.. i needed something to work so i reverted using the low level commands..

10:57 <PaulFertser> And if you're not doing anything in batch then speed shouldn't be a concern :)

10:58 <PaulFertser> What are you trying to do with the target?

10:58 <Battosai42> i did not need batch so far but i will in the future, just did not get to it yet..

10:59 <Battosai42> ok, perhaps i can try defining the target again, could be its related.. would be nicer anyhow..

11:00 <PaulFertser> Battosai42: you can specify some other stable end state for drscan.

11:01 <Battosai42> for now what i need to do is access the APB bus of the system ant read/write register contents mostly on the periphery, not the M3 itself, thats just 1 of 5 access points in the DAP

11:03 <Battosai42> i could do that, not sure what it would gain me though.. from my understanding, RUN/IDLE is the correct state

11:03 <karlp> not wanting batch, and not wanting to use the built in fast modes, but still complaining that it's slow is kinda like beaitng your head on the wall and asking why it hurts?

11:05 <Battosai42> i am happy to use the built in mode, just did not work, but i am sure that was my mistake.. just trying to understand it all , not complaining! :-)

11:06 <PaulFertser> Battosai42: mdw/mww usually works just fine to access memory-mapped peripherals.

11:07 <Battosai42> i will give that a try, thanks!