12:50 <NishanthMenon> https://usercontent.irccloud-cdn.com/file/rSiAcDL1/DSView-231017-220805.png

12:51 <NishanthMenon> I am missing something here -> I am trying to configure reset correctly on TI's mspm0 launchpad, it has just nRST, so, I configured reset_config srst_only srst_push_pull and it gave me the above pulse. nicely. but reset init -> reports "timed out while waiting for target halted"

12:53 <PaulFertser> NishanthMenon: reset init is "reset halt" plus running reset-init handler after that. So "reset halt" is what you're trying to do.

12:53 <PaulFertser> NishanthMenon: reset halt normally works by setting vector catch to stop on reset handler and then by doing reset (physical pulse if that's enabled)

12:54 <NishanthMenon> PaulFertser: -> yep -if i do "reset;init;halt" -> it throws "timed out while waiting for target halted", but "reset; init; sleep 1000; halt" works great. this would make sense that the startup time is a bit long

12:54 <PaulFertser> NishanthMenon: so if the target is buggy and e.g. debug unit is reset too on nRST signal then it won't going to halt because the vector catch wouldn't work.

12:54 <PaulFertser> Another possibity is "secret" ROM bootloader which is designed in a way to make halting on the first instruction impossible.

12:55 <PaulFertser> NishanthMenon: don't do "init" there. Init makes sense just once in the whole OpenOCD session, it just changes from configuration mode to runtime mode (of OpenOCD itself, some commands are only available during either of states)

12:56 <PaulFertser> Does this clear up the confusion?

12:56 <NishanthMenon> PaulFertser: ok. is there any variable I can set to tell openOCD that system is ready after x ms of reset? swd adapter does'nt seem to like jtag_ntrst_delay

12:57 <PaulFertser> NishanthMenon: is ready for what? "reset halt" _needs_ a way to stop at the first instruction of the reset handler.

12:57 <PaulFertser> That's semantics.

12:57 <NishanthMenon> aah true

12:57 <PaulFertser> If you want to just stop at about arbitrary time you can do "reset; sleep 1000; halt" and that's it.

12:58 <NishanthMenon> PaulFertser: yup - just that "program" seems to invoke reset init behind the scene

12:58 <PaulFertser> btw, TRST is a signal from JTAG standard, it's meant to reset the state of only JTAG state machine and is not really needed as the state machine can be reset by other way.

12:59 <PaulFertser> NishanthMenon: it does, yes. Because for programming flash you need to make sure the target is in some particular, always the same state.

13:00 <PaulFertser> Imagine there's firmware that enables watchdog early on or some peripheral ISR. If you try to run target flash helper in that state you are going to get unpredictable results.

13:00 <NishanthMenon> :) yes indeed - there is definitely a wdt that runs by default on startup.. ;)

13:01 <NishanthMenon> ok - the proper solution will be to find a way to get the system to do a halt at very start.. let me dig at specs more.. there ought to be a way

13:01 <NishanthMenon> thanks as usual PaulFertser ..

13:01 <PaulFertser> NishanthMenon: always welcome :)

13:02 <PaulFertser> NishanthMenon: ti_cc3220sf.cfg is an example of a workaround

13:02 <NishanthMenon> PaulFertser: aah thanks

13:03 <PaulFertser> psoc6.cfg too

13:03 <PaulFertser> But it would be better to find a more reliable solution of course.

14:48 <NishanthMenon> PaulFertser: thanks