2

I'm try to reproduce the result of benchmarking at here

I use STM32F429 Nucleo-144 board and Ubuntu 20.04 with VMWare on Windows10.

When I run benchmarks.py in terminal, Serial.read() returns empty bytes, b''.

Here is the snippet of the code:

import serial

dev = serial.Serial("/dev/ttyACM0", 115200,timeout=10)

def benchmarkBinary(binary):
    print("Flashing {}..".format(binary))
    subprocess.run(["st-flash", "write", binary, "0x8000000"],
               stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)
    print("Flashed, now running benchmarks..".format(binary))
    state = 'waiting'
    marker = b''
    # This parses test vector output starting with a number of leading '=',
    #  and expects a hashtag '#' after the test vector output.
    while True:
        x = dev.read()
        if x == b'' and state == 'waiting':
            print('x =', x)
            print('state =', state)
            print("timed out while waiting for the markers")
            return benchmarkBinary(binary)

And the printed result is as following:

Flashing benchmark-kindi256342.bin..
Flashed, now running benchmarks..
x = b''
state = waiting
timed out while waiting for the markers
Flashing benchmark-kindi256342.bin..

What should I do? Is there any way to run the binaries?

x = b''
state = waiting

is added by me and it is not in the original code. And the message above is printed repeatedly since x and state values are fixed.

I checked the initial baud rate of STM32F429 Nucleo-144 is 115200, which is written in the original code. And I changed /dev/ttyUSB0 to /dev/ttyACM0 since there is no /dev/ttyUSB0 in the board.

I checked there is no problem with ST-link and gcc-arm-none-eabi. Also I checked the board is connected correctly.

I assume that there may be some problems with virtual environments, but I can't sure.

I also tried to run other binary code, but there is no messages even codes are flashed well, and pressed RESET button.

khelwood
  • 55,782
  • 14
  • 81
  • 108
  • First off, don't use a recursive call to repeat the function; just use another loop if it's needed, but I don't see why the existing `while True:` loop isn't sufficient. Second, *what part of the code is supposed to cause `state` to change?* Third, *why should `dev.read()` read anything*? Why do you expect that there is any data to read from the device, and what should it look like? – Karl Knechtel Feb 01 '23 at 09:57
  • "I changed /dev/ttyUSB0 to /dev/ttyACM0 since there is no /dev/ttyUSB0 in the board." What happens if you try reading from `/dev/ttyACM0` at the command line (like with `dd`)? – Karl Knechtel Feb 01 '23 at 09:59
  • This code is not mine, so I don't know why the while loop is used. However, I assume that the loop is needed when there is no data from `.read()` or `state` is 'waiting'. To help your understand, please see the `benchmarks.py` code in the repository. The code has too many characters so I can't copy and paste here. – Yong Ryeol Choi Feb 01 '23 at 10:27
  • @KarlKnechtel And there is no data has been read by read(). Only b'' returned after reading. – Yong Ryeol Choi Feb 01 '23 at 11:55
  • Right; so what I am thinking is, perhaps there is a problem outside of the code that prevents the device from offering any data to read. – Karl Knechtel Feb 01 '23 at 11:57
  • @KarlKnechtel Can you explain it in detail? I assume the 'prevention' is from OS(e.g. kernel), or the virtual machine, but not sure. – Yong Ryeol Choi Feb 01 '23 at 12:59
  • It could be any number of things, I think. I don't have this hardware, so I wouldn't be able to test it. – Karl Knechtel Feb 01 '23 at 13:13

0 Answers0