[feature] Added connect under reset to stlink_open_usb( )

[geoffreymbrown]

I've added a small change to stlink_open_usb to support connect under reset. In addition, I added an option to tests/usb.c (--reset or --no-reset) to use this mode.

[geoffreymbrown]

Mea culpa. There are times when vscode does too much. Geoffrey

…

On Fri, May 22, 2020 at 4:00 PM nightwalker-87 ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In .vscode/settings.json <#963 (comment)>: > @@ -0,0 +1,3 @@ +{ + "cmake.configureOnOpen": false +} Note: We don't need this IDE-specific config in the codebase. Can you remove it? — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#963 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANL6URWSKGPJPORDDBQ45DRS3KV5ANCNFSM4NIB5PHQ> .

[chenguokai]

As far as I have seen, the code added a new argument to tests/usb.c, not to the existing utilities like st-flash, while the original issue refers to st-flash. Would you be kind enough to add this argument for st-flash?

Relevant files are tools/flash_opts.c, tools/flash.c and some relevant headers.

[geoffreymbrown]

I can but I need a bit more guidance. What flag should I add ? --connect-under-reset ? Since the flash tool halts the processor in any case, the right behavior is probably to 1) connect under reset 2) force debug 3) release the reset 4) reread the chip info (under reset, the flash size isn't returned properly) Should I make those changes ? I have limited ways to test them, but they would be localized to that option flag. Geoffrey

…

On Fri, May 22, 2020 at 11:13 PM Xim ***@***.***> wrote: As far as I have seen, the code added a new argument to tests/usb.c, not to the existing utilities like st-flash, while the original issue refers to st-flash. Would you be kind enough to add this argument for st-flash? Relevant files are tools/flash_opts.c, tools/flash.c and some relevant headers. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#963 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANL6UVD4SUCSK6CQ3JYI5TRS45MFANCNFSM4NIB5PHQ> .

[chenguokai]

@Nightwalker-87 Maybe you are the best person to make decisions on this kind of issues:-)

[geoffreymbrown]

I'll do it in the next couple of days. Probably should do the same for st-info.

…

On Sat, May 23, 2020 at 7:46 AM Xim ***@***.***> wrote: @Nightwalker-87 <https://github.com/Nightwalker-87> Maybe you are the best person to make decisions on this kind of issues:-) — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#963 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANL6UTJNHIGYLPT6ZNZ2NLRS6ZRXANCNFSM4NIB5PHQ> .

[Nightwalker-87]

I can but I need a bit more guidance. What flag should I add ? --connect-under-reset ?

I think that is what @chenguokai referred to. You can proceed as proposed, but we will need someone to test it before merging.

[geoffreymbrown]

I've added the additional code to my branch -- the other pull request was still in progress, so I'm not quite sure how to proceed. I tested the code with an stm32l476RG nucleo board executing the attached small program which blinks a bit and then goes to standby mode with the debugger interface disabled. Without the --connect-under-reset flag both st-info and st-flash fail. With the flag they both execute successfully. The code is (relatively) non-invasive. Other than checking for the flag and passing it to the usb open routine, it doesn't do anything. I did have to extend the usb open code a bit to force debug mode and release the reset line in order to minimize the changes to st-info and st-flash

[Nightwalker-87]

@geoffreymbrown: This PR has been updated automatically with the update to your branch. Thx for testing and the related description. Looks good to me. 👍

[Nightwalker-87]

@chenguokai: Can you review the updated changes as well?

[Nightwalker-87]

Thx for your contribution @geoffreymbrown.