#153 Error running stm32flash with QProcess (qt)

[Enrico Razzaboni]

Hi, i'm trying to run stm32flash with qt process, but it gives "device not specified" error.
but running the same command on terminal, it works.
i'm using version 0.7.

QProcess *loadFirmware = new QProcess();
loadFirmware->start("stm32flash", QStringList() << "-b 9600 -w /run/media/sdb1/LandingBuilds/bool_cnt/Control.bin /dev/ttyUSB0");
loadFirmware->waitForFinished(-1);
qDebug() << loadFirmware->readAllStandardError();
qDebug() << loadFirmware->readAllStandardOutput();

[Tormod Volden]

Yes, wrapping it in bash script shouldn't change much (although the sleep could change things if is was a timing-sensitive issue). bash will wait for its subprocess stm32flash to finish. But whatever Qt keeps doing it will interfere with the launched process and the subprocesses the same way. I would think waitForFinished() should make the process keep running in peace. With the minimal example there is not even an event loop running. Is your embedded host at its limits? Would stm32flash directly from the command line also fail if you have other busy processes on the host?

[Enrico Razzaboni]

stm32flash never failed from the command line. my host is not at limit (3/6% cpu)

[Tormod Volden]

You can try something like:
strace -o /tmp/trace.log -f -tt ./testqprocess fw.bin
and attach the log.

[Enrico Razzaboni]

here it is

[Tormod Volden]

Is this from the minimal test program?

If you can reproduce the issue with a simple program, there is no reason to analyze it with a complex one.

[Enrico Razzaboni]

it's the .sh file with gpio and sleep command

[Tormod Volden]

Then compare it with running stm32flash directly
strace -o /tmp/trace2.log -f -tt stm32flash -w fw.bin /dev/ttyUSB0

[Enrico Razzaboni]

i don't see any difference, except the reply of stm32 micro

[Tormod Volden]

trace2.log (stm32flash directly):

4642  12:37:35.681615 ioctl(5, TCFLSH, TCIFLUSH) = 0
4642  12:37:35.681709 write(5, "\177", 1) = 1   -------------INIT
4642  12:37:35.681848 read(5, "", 1)    = 0   ---- read that times out
4642  12:37:36.188335 write(5, "\177", 1) = 1  -------------- INIT
4642  12:37:36.188486 read(5, "\37", 1) = 1   --------------- NACK
4642  12:37:36.198191 write(5, "\1\376", 2) = 2  -- Get Version and RP Status
4642  12:37:36.198311 read(5, "y", 1)   = 1   --------------- ACK
4642  12:37:36.214121 read(5, "1\0\0", 3) = 3   --- answer to Get Version
4642  12:37:36.214215 read(5, "y", 1)   = 1  --------------- ACK
4642  12:37:36.214305 write(5, "\0\377", 2) = 2 -- Get Version and Commands
4642  12:37:36.214414 read(5, "y", 1)   = 1  --------------- ACK

The NACK is because it was not power-cycled or reset since last run, so the INIT command won't be recognized. stm32flash is clever enough to deal with this and it continues.

trace.log (via QProcess and bash script):

4523  12:13:05.376449 ioctl(5, TCFLSH, TCIFLUSH) = 0
4523  12:13:05.376530 write(5, "\177", 1) = 1  ------------- INIT
4523  12:13:05.376628 read(5, "", 1)    = 0   ---- read that times out
4523  12:13:05.884338 write(5, "\177", 1) = 1  ------------- INIT
4523  12:13:05.884488 read(5, "y", 1)   = 1   --------------- ACK
4523  12:13:05.887146 write(2, "Failed to init device after retr"..., 35) = 35

In this case I believe it was power-cycled so it replies ACK but too late.

So maybe it is not related to QProcess or not, but to you power-cycling or resetting the device differently in the two cases.

Please use the minimal test program, and make sure resetting or power-cycling has been done exactly the same way in both cases.

[Enrico Razzaboni]

Hi, after a lot of tests, now it works. i've added a sleep of 2 seconds after set reset pin to high