07:25 <gamiee> zapb_ : I do not need to reset device for flsah operations, it's just I wanted to improve current reset mechanism. (although, flash functions breaks some stuff and CPU should be rebooted afterwards, but that is what's happening)

08:32 <gamiee> There is one thing which is strange. When the chip needs custom software reset, reset-assert event in TCL is used. Although, this replaces the original mechanism, which is then required to be manually implemented within TCL. But what is worse is, that this event doesn't receive information, if the core should be halted after reset or not, and this information needs to be get with hack. GD32VF103 target TCL script is good example: https://github.com/openocd-

08:32 <gamiee> org/openocd/blob/master/tcl/target/gd32vf103.cfg

08:34 <gamiee> And I need to do the same for BL702 target as well. I was thinking if maybe I can do the "final sw reset" in reset-assert-post, but the documentation here is kinda lacking and I am not sure where it is being called (only reference is in startup tcl script)

09:18 <zapb_> gamiee, you mean you don't have information if somebody called "reset init" or "reset halt" in the Tcl handler?

09:38 <gamiee> zapb_: correct

09:38 <gamiee> You need to save it in init_reset : https://github.com/openocd-org/openocd/blob/master/tcl/target/gd32vf103.cfg#L112C1-L112C27

10:15 <zapb_> gamiee, and that's not possible for you? Not sure why we have init_reset and do not pass the mode to reset-assert :-/

10:15 <zapb_> maybe PaulFertser or borneoa___ have an idea

10:15 <zapb_> If not, you could ask on the ML

10:19 <gamiee> zapb_ : it is possible, just I was wondering if we couldn't rather pass halt and other information to reset-assert event. (just want to know if this is intentional or not, and if not and keen for changing, how I should do it)

10:20 <gamiee> Isn't ML abandoned?

10:20 <gamiee> Also i am thinking about using reset-assert-post if it will still work fine... will know in next few hours when I will come home :D

10:28 <borneoa___> The current model for 'events' is to call TCL procs with no parameters

10:35 <zapb_> gamiee, no, ML is not abandoned

10:37 <zapb_> borneoa___, but there is no 'good' reason for it, is there? I mean using global variables to pass parameters around does not look like a proper design decision :D

10:38 <borneoa___> I have noticed that the TCL variable $halt is accessible in the reset-related events. I don't see it tagged as global, so it looks more as a corner case than an intentional behavior.

10:40 <borneoa___> zapb_: reset command is global, not per target. So a global variable could do the job. But a more clean way to pass parameters to events should be studied

10:44 <zapb_> borneoa___, yep, agreed. It does the job but it's not the most intuitive way for users

10:51 <gamiee> borneoa___ I think it would help a lot to have those arguments available.

10:52 <gamiee> I really hope that reset-assert-post will work for my use-case, that way I don't need to do those hacks and it would be elegant, will see.

11:07 <zapb_> gamiee, if it is possible with the current "hack", just use it. If we come in the future to the conclusion that passing arguments work, your code will be adapted

11:08 <zapb_> gamiee, maybe drop some comment to indicate that this is a "workaround"

11:55 <gamiee> zapb_ okay :) thanks for info.

16:35 <gamiee> So, i moved the code to reset-assert-post , and it works, only thing is that on every first action, it spams bunch of "Error: Failed to read priv register." but after it just works

16:43 <gamiee> I really wonder what's different.

17:06 <zapb_> gamiee, I think it would be helpful to see your config and debug log (use a pastebin)

17:25 <gamiee> zapb_ good ideqa

17:25 <gamiee> although openocd debug is really really verbose, the file have 1.5MB :D

17:27 <gamiee> interesting thing is, that only thing which is different, is timing.

17:28 <gamiee> and clearing out progbuf_cache

17:47 <gamiee> hah okay, yeah, that's it, progbuf cache