08:06 <JoseT> Reposting message from yesterday. Any help is highly appreciated.

08:06 <JoseT> Hi, I have a special situation to be handled in my device in sleep mode. When the device is running with sleep enabled, the reset bit in dhcsr register may get set. This is by design of the device and nothing can be done. If I have a customized check and make the target->state to TARGET_RUNNING when the reset bit is set during sleep, debug works.

08:06 <JoseT> This is in cortex_m_poll_one() function in cortex_m.c. I am unable to find a solution that can be upstreamed. This changes are still my internal fork. Could anyone give suggestions on how to handle this in openocd repo? Please share any similar gerrit if available.

08:48 <PaulFertser> Hey JoseT

08:49 <PaulFertser> JoseT: can you clarify if the core is indeed getting reset in that sleep mode or not? Are the Arm CPU registers preserved? Does it continue running from the reset vector or from the program counter after resuming from sleep?

08:56 <JoseT> THanks PaulFertser for your response. Core is not entirely getting reset. The code will continue running from PC after resuming from sleep.

08:58 <JoseT> openocd while seeing the reset bit set in the DHCSR register during the poll, assumes that actually a reset has happened and move the target state to Reset. But in my case the device should continue running from PC

08:59 <JoseT> or in other words stay in TARGET_RUNNING state

09:01 <PaulFertser> JoseT: does the device actually continue running from PC? If yes, what's the rationale to set that reset bit, and do you think it's compliant to Arm Cortex specification?

09:06 <stefanct_> i am working on some targets that contain a lot of fuses, and at least some of them will most probably be written in any actual product. therefore I would like to supply some helper tcl procedures that are only to be called when bringing up a new system once (or query its state later). i have not found any docs or examples that deal with such

09:06 <stefanct_> things. are such things suitable for the main repository at all? i am mostly wondering about the directory and file names and naming conventions of the procedures.

09:18 <PaulFertser> stefanct_: hey! Whatever makes sense for bringup or production can go into target config, why not?

09:21 <stefanct_> dunno, i just had the feeling that there is only code that is directly necessary to get systems booting and to debug them exists

09:21 <PaulFertser> There's no established naming convention for that. You can find e.g. sheevaplug_reflash_uboot, ar9331_25mhz_pll_init, setupUART0, flashUBOOT, etc.

09:21 <PaulFertser> Whatever makes sense for the users, matching the documentation or appnotes should be good.

09:22 <PaulFertser> OpenOCD aims to be useful for all potential uses of OCD.

09:24 <stefanct_> i am concerned about naming conflicts. ATM i have read_fuse etc. AFAICT the namespace of procedures is shared between all files in tcl/target, correct?

09:29 <PaulFertser> stefanct_: partially. It depends on what target configs are sourced. If there's a JTAG chain with several targets then indeed different configs will be sourced to handle them and that opens a possibility for name clashes. So probably adding a reasonable prefix to proc names is a good idea.

09:29 <stefanct_> hm, i was puzzled because i could call a function via telnet without "importing" it first with script or something, but i cant reproduce that now...

09:30 <PaulFertser> stefanct_: if the proc is defined in target config you can just call it from telnet, GDB or RPC without any additional tricks.

09:30 <PaulFertser> In the target config that was loaded of course, not just sitting there in the file system.

09:30 <stefanct_> sure but it isnt really. it's in its own file

09:31 <stefanct_> no idea how i managed to do that tbh. i restarted oocd before that

09:31 <PaulFertser> If this file is sourced on startup then you can call it. If not, you need to load it first.

09:31 <stefanct_> sorry for the noise

09:31 <PaulFertser> np :)

09:31 <PaulFertser> You can always run with -d3 to see what commands are getting from where.

09:53 <PaulFertser> JoseT: not sure if you answered, your client joins and parts, have you seen my last question?

10:04 <JoseT> I just checked the log to see your response. Sorry I have some problem with my connection.. Anyway...

10:04 <JoseT> Its because of  retention meachanism we have in our device.. I will check with hardware experts about compliance. But surely we continue runnig from PC in this case.

10:05 <JoseT> All the information for Debug is maintained when we enter full standby

10:05 <JoseT> PaulFertser

10:30 <PaulFertser> JoseT: maintaining debug state is the norm for cortex, even under full system reset.

10:30 <PaulFertser> JoseT: I'm asking about those details because if it's just one non-compliant chip which is even not available to the general public then probably upstreaming a quirk for it is not really needed?

10:38 <JoseT> Device is in market and Tools are already supporting this. Device is compliant, just that retaining mechanism is bit different here. I will also look at alternate options to connect while coming back from standby, but the usual check in cortex_m_poll_one() fucntion wont hold good. If there are changes like this, how is it suppose to be handled by

10:38 <JoseT> vendors?

10:56 <PaulFertser> JoseT: I do not understand why you say it's compliant when the Arm docs clearly mention "core reset" and you say the core isn't really reset (or at least it's fully rolled back to the previous state).

11:01 <Haohmaru> "quantum compliant"

11:08 <JoseT> Thanks karlp Haohmaru for your observations :D.

11:08 <JoseT> PaulFertser - Typically the cpu should have a full retention to keep the register state , but for my device thats not the case. I am yet to get response from my hardware engineers about the background. Meantime I am trying to understand, how a scenario like this can be handled in openocd if its an option

11:09 <Haohmaru> but i didn't say anything useful ;P~

23:50 <Getty> that reminds me now of the horrible experience i had with that wifi chip now

23:50 <Getty> where "Reset the module" doesnt mean disconnect the wifi :D