STM32_Programmer_CLI ignores Debug Authentication parameters given on command line
Hi,
I’m setting up a bash script (under Ubuntu Linux) to automate STM32H563 provisioning for my application using the command-line version of STM32 Cube Programmer. As part of this script, I’m setting it up to automatically perform Full Regression prior to new provisioning if the board is already provisioned. (This is being used for testing and software development, so I am likely to need to do this.)
The help text tells me that I can use the “key”, “cert” and “per” arguments on the command line, along with debugauth=1, to specify paths to the key, certificate and requested permission to request debug authentication. However, the application seems to ignore these arguments completely and always asks for them to be entered in the console, so I can’t perform a scripted Full Regression as should be possible.
I tried working around this by piping the output of a bash printf command into the application instead. Oddly, this seems to work for passing in the key and certificate but the selection of permission/action to perform which I fed to stdin was ignored; it almost looks like something is deliberately consuming all queued input prior to offering the option.
I initially observed this in STM32_Programmer_CLI version 2.14.0. I just upgraded to the newest version 2.22.0 and am seeing almost exactly the same behaviours in that. Both versions ignore these command line arguments. For the piping of options into the application, 2.14.0 just sat waiting for more input (which won’t come as it already consumed what I prepared), while 2.22.0 ignored my selection but then appeared to accept the following newline, causing authentication to fail because of an invalid permission selection.
This leaves me unable to implement the scripted behaviour I want. Am I doing something wrong, or is this a bug in STM32_Programmer_CLI? If it’s a bug, please can you fix it for the next release?
I don’t seem to be the only person affected by this. On this page:
PieterG mentions the same issue but with password rather than certificate-based authentication.
Thanks and best regards
Paul