Mbed-os: ST-Link interface doesn't work with greentea on mac os

[LiyouZhou]

Description

• Type: Bug

---

Bug

Target
UBLOX_EVK_ODIN_W2 and NUCLEO_F429ZI

DAPLink version:
0200 works
0221 fails

Actual behavior
There is no output from the device serial console. when running mbedgt -v -V hence tests fail

[0xc0170]

cc @c1728p9 @bridadan

[bridadan]

@LiyouZhou Can you say which version of ST-Link you're using? Specifically, what is the version you downloaded from the ST website? The DAPLink version number in ST-Link releases unfortunately isn't usually up to date.

[LiyouZhou]

V2J28M18

[0xc0170]

cc @bcostm @adustm @LMESTM @jeromecoutant - to be aware

[bridadan]

@LiyouZhou I just updated a NUCLEO_F429ZI to V2J28M18 and I can successfully run mbed OS tests on it from Windows 10. Can you be more specific about your environment and project? What host OS are you using? Where are your tests located?

[LiyouZhou]

I am on Mac os. I suspect Linux might behave similar.

[jeromecoutant]

Hi

Test done with this configuration:

• MacBook Pro : OS X Yosemite – Version 10.10.15
• STLink FW : V2J28M18
• Boards : Nucleo-F429ZI
• IDE : SW4STM32
  STLink detection and enumeration OK.
  Drag and drop OK
  Run and debug OK with IDE

@LiyouZhou when you say "New version of st-link interface firmware doesn't work", I understand "V2J28M18" doesn't work. Do you know which version was working ?

[LiyouZhou]

I am talking about mbed greantea, there is problem with reset and serial communication. @mazimkhan

[mazimkhan]

@LiyouZhou can you please paste a log here. As per Brian V2J28M18 works.

[LiyouZhou]

@mazimkhan here is the log.

> mbedgt -v -V
mbedgt: greentea test automation tool ver. 1.2.5
mbedgt: using multiple test specifications from current directory!
    using 'BUILD/tests/UBLOX_EVK_ODIN_W2/GCC_ARM/test_spec.json'
test_spec
mbedgt: detecting connected mbed-enabled devices...
mbedgt: detected 2 devices
    +-------------------+----------------------+-------------------------+-----------------+--------------------------------------------------+
    | platform_name     | platform_name_unique | serial_port             | mount_point     | target_id                                        |
    +-------------------+----------------------+-------------------------+-----------------+--------------------------------------------------+
    | K64F              | K64F[0]              | /dev/tty.usbmodem141332 | /Volumes/MBED   | 024002265f1d1e48000000000000000000000000a2c4e3f0 |
    | UBLOX_EVK_ODIN_W2 | UBLOX_EVK_ODIN_W2[0] | /dev/tty.usbmodem141423 | /Volumes/MBED 1 | 123602210A4D671D3509E416                         |
    +-------------------+----------------------+-------------------------+-----------------+--------------------------------------------------+
test_build {u'mbed-os-tests-integration-basic': <mbed_greentea.tests_spec.Test instance at 0x1043a9b00>}
mbedgt: processing target 'UBLOX_EVK_ODIN_W2' toolchain 'GCC_ARM' compatible platforms... (note: switch set to --parallel 1)
    +-------------------+----------------------+--------------------------------+-----------------+--------------------------+
    | platform_name     | platform_name_unique | serial_port                    | mount_point     | target_id                |
    +-------------------+----------------------+--------------------------------+-----------------+--------------------------+
    | UBLOX_EVK_ODIN_W2 | UBLOX_EVK_ODIN_W2[0] | /dev/tty.usbmodem141423:115200 | /Volumes/MBED 1 | 123602210A4D671D3509E416 |
    +-------------------+----------------------+--------------------------------+-----------------+--------------------------+
mbedgt: running 1 test for platform 'UBLOX_EVK_ODIN_W2' and toolchain 'GCC_ARM'
    use 1 instance of execution threads for testing
mbedgt: checking for 'host_tests' directory above image directory structure
    found 'host_tests' directory in: 'mbed-os/TESTS/host_tests'
mbedgt: selecting test case observer...
    calling mbedhtrun: mbedhtrun -m UBLOX_EVK_ODIN_W2 -p /dev/tty.usbmodem141423:115200 -f "BUILD/tests/UBLOX_EVK_ODIN_W2/GCC_ARM/mbed-os/TESTS/integration/basic/basic.bin" -e "mbed-os/TESTS/host_tests" -d /Volumes/MBED 1 -C 4 -c shell -t 123602210A4D671D3509E416
mbedgt: mbed-host-test-runner: started
[1496681116.36][HTST][INF] host test executor ver. 1.1.8
[1496681116.36][HTST][INF] copy image onto target...
[1496681116.36][COPY][INF] Waiting up to 60 sec for '123602210A4D671D3509E416' mount point (current is '/Volumes/MBED 1')...
[1496681125.96][HTST][INF] starting host test process...
[1496681125.96][CONN][INF] starting connection process...
[1496681125.96][CONN][INF] notify event queue about extra 60 sec timeout for serial port pooling
[1496681125.96][CONN][INF] initializing serial port listener...
[1496681125.96][PLGN][INF] Waiting up to 60 sec for '123602210A4D671D3509E416' serial port (current is '/dev/tty.usbmodem141423')...
[1496681125.96][HTST][INF] setting timeout to: 60 sec
[1496681126.37][SERI][INF] serial(port=/dev/tty.usbmodem141423, baudrate=115200, read_timeout=0.01, write_timeout=5)
[1496681126.37][SERI][INF] reset device using 'default' plugin...
[1496681126.77][SERI][INF] waiting 1.00 sec after reset
[1496681127.77][SERI][INF] wait for it...
[1496681127.77][SERI][TXD] mbedmbedmbedmbedmbedmbedmbedmbedmbedmbed
[1496681127.77][CONN][INF] sending up to 2 __sync packets (specified with --sync=2)
[1496681127.78][CONN][INF] sending preamble 'b8ffb1d9-2771-4ad2-9189-cdddb36e3504'
[1496681127.78][SERI][TXD] {{__sync;b8ffb1d9-2771-4ad2-9189-cdddb36e3504}}
[1496681127.79][CONN][RXD] $$$123602210A4D671D3509E416init_spi: instance=0x40013400
[1496681127.79][CONN][RXD] spi_format, bits:8, mode:0, slave?:0
[1496681127.79][CONN][RXD] init_spi: instance=0x40013400
[1496681127.79][CONN][RXD] spi_frequency, request:1000000, select:656250
[1496681128.78][CONN][INF] resending new preamble '3f65393c-8413-44c5-8a94-087b455710c9' after 1.00 sec
[1496681128.78][SERI][TXD] {{__sync;3f65393c-8413-44c5-8a94-087b455710c9}}
[1496681186.96][HTST][INF] test suite run finished after 61.00 sec...
[1496681186.96][CONN][INF] received special even '__host_test_finished' value='True', finishing
[1496681186.97][HTST][INF] CONN exited with code: 0
[1496681186.97][HTST][INF] No events in queue
[1496681186.97][HTST][INF] stopped consuming events
[1496681186.97][HTST][INF] host test result(): None
[1496681186.97][HTST][WRN] missing __exit event from DUT
[1496681186.97][HTST][WRN] missing __exit_event_queue event from host test
[1496681186.97][HTST][ERR] missing __exit_event_queue event from host test and no result from host test, timeout...
[1496681186.97][HTST][INF] calling blocking teardown()
[1496681186.97][HTST][INF] teardown() finished
[1496681186.97][HTST][INF] {{result;timeout}}
mbedgt: checking for GCOV data...
mbedgt: mbed-host-test-runner: stopped and returned 'TIMEOUT'
mbedgt: test case summary event not found
    no test case report present, assuming test suite to be a single test case!
    test suite: mbed-os-tests-integration-basic
    test case: mbed-os-tests-integration-basic
mbedgt: test on hardware with target id: 123602210A4D671D3509E416
mbedgt: test suite 'mbed-os-tests-integration-basic' ................................................. TIMEOUT in 71.10 sec
    test case: 'mbed-os-tests-integration-basic' ................................................. ERROR in 71.10 sec
mbedgt: test case summary: 0 passes, 1 failure
mbedgt: all tests finished!
mbedgt: shuffle seed: 0.8700783930
mbedgt: test suite report:
+---------------------------+-------------------+---------------------------------+---------+--------------------+-------------+
| target                    | platform_name     | test suite                      | result  | elapsed_time (sec) | copy_method |
+---------------------------+-------------------+---------------------------------+---------+--------------------+-------------+
| UBLOX_EVK_ODIN_W2-GCC_ARM | UBLOX_EVK_ODIN_W2 | mbed-os-tests-integration-basic | TIMEOUT | 71.1               | shell       |
+---------------------------+-------------------+---------------------------------+---------+--------------------+-------------+
mbedgt: test suite results: 1 TIMEOUT
mbedgt: test case report:
+---------------------------+-------------------+---------------------------------+---------------------------------+--------+--------+--------+--------------------+
| target                    | platform_name     | test suite                      | test case                       | passed | failed | result | elapsed_time (sec) |
+---------------------------+-------------------+---------------------------------+---------------------------------+--------+--------+--------+--------------------+
| UBLOX_EVK_ODIN_W2-GCC_ARM | UBLOX_EVK_ODIN_W2 | mbed-os-tests-integration-basic | mbed-os-tests-integration-basic | 0      | 1      | ERROR  | 71.1               |
+---------------------------+-------------------+---------------------------------+---------------------------------+--------+--------+--------+--------------------+
mbedgt: test case results: 1 ERROR
mbedgt: completed in 72.34 sec
mbedgt: exited with code 1

[LiyouZhou]

I think @bridadan is working on windows where I am using a mac.

[bridadan]

@LiyouZhou Are the following lines from the log coming from your application? These are being received from the device. It is not normal for the test mbed-os-tests-integration-basic to be printing these messages.

[1496681127.79][CONN][RXD] $$$123602210A4D671D3509E416init_spi: instance=0x40013400
[1496681127.79][CONN][RXD] spi_format, bits:8, mode:0, slave?:0
[1496681127.79][CONN][RXD] init_spi: instance=0x40013400
[1496681127.79][CONN][RXD] spi_frequency, request:1000000, select:656250

[bridadan]

Ah, it seems that those are debug prints that are coming from the STM hal. What version of mbed OS are you using? If you have the project uploaded somewhere, could you send it to me?

It looks like greentea is receiving printfs from the device, however the device is not responding to the sync commands. If you're using any released version of mbed OS though this shouldn't be an issue of the device crashing since we test for that before each release for that platform.

[LiyouZhou]

Ok Lets try again:

> mbed new myprog
[mbed] Creating new program "myprog" (git)
[mbed] Adding library "mbed-os" from "ssh://[email protected]/ARMmbed/mbed-os.git" at branch latest
[mbed] Updating reference "mbed-os" -> "https://github.com/ARMmbed/mbed-os/#5fff7e1daeb395aa3d1ecf3f9ec3f4fead3de0c2"
>  cd myprog
>  mbed target UBLOX_EVK_ODIN_W2
[mbed] UBLOX_EVK_ODIN_W2 now set as default target in program "myprog"
>  mbed toolchain GCC_ARM
[mbed] GCC_ARM now set as default toolchain in program "myprog"
>  mbed test -n mbed-os-tests-integration-basic
...
...
> mbedgt -v -V
mbedgt: greentea test automation tool ver. 1.2.5
mbedgt: using multiple test specifications from current directory!
    using 'BUILD/tests/UBLOX_EVK_ODIN_W2/GCC_ARM/test_spec.json'
test_spec
mbedgt: detecting connected mbed-enabled devices...
mbedgt: detected 1 device
    +-------------------+----------------------+-------------------------+---------------+--------------------------+
    | platform_name     | platform_name_unique | serial_port             | mount_point   | target_id                |
    +-------------------+----------------------+-------------------------+---------------+--------------------------+
    | UBLOX_EVK_ODIN_W2 | UBLOX_EVK_ODIN_W2[0] | /dev/tty.usbmodem141423 | /Volumes/MBED | 123602210A4D671D3509E416 |
    +-------------------+----------------------+-------------------------+---------------+--------------------------+
test_build {u'mbed-os-tests-integration-basic': <mbed_greentea.tests_spec.Test instance at 0x10e642b00>}
mbedgt: processing target 'UBLOX_EVK_ODIN_W2' toolchain 'GCC_ARM' compatible platforms... (note: switch set to --parallel 1)
    +-------------------+----------------------+------------------------------+---------------+--------------------------+
    | platform_name     | platform_name_unique | serial_port                  | mount_point   | target_id                |
    +-------------------+----------------------+------------------------------+---------------+--------------------------+
    | UBLOX_EVK_ODIN_W2 | UBLOX_EVK_ODIN_W2[0] | /dev/tty.usbmodem141423:9600 | /Volumes/MBED | 123602210A4D671D3509E416 |
    +-------------------+----------------------+------------------------------+---------------+--------------------------+
mbedgt: running 1 test for platform 'UBLOX_EVK_ODIN_W2' and toolchain 'GCC_ARM'
    use 1 instance of execution threads for testing
mbedgt: checking for 'host_tests' directory above image directory structure
    found 'host_tests' directory in: 'mbed-os/TESTS/host_tests'
mbedgt: selecting test case observer...
    calling mbedhtrun: mbedhtrun -m UBLOX_EVK_ODIN_W2 -p /dev/tty.usbmodem141423:9600 -f "BUILD/tests/UBLOX_EVK_ODIN_W2/GCC_ARM/mbed-os/TESTS/integration/basic/basic.bin" -e "mbed-os/TESTS/host_tests" -d /Volumes/MBED -C 4 -c shell -t 123602210A4D671D3509E416
mbedgt: mbed-host-test-runner: started
[1496740618.70][HTST][INF] host test executor ver. 1.1.8
[1496740618.70][HTST][INF] copy image onto target...
[1496740618.70][COPY][INF] Waiting up to 60 sec for '123602210A4D671D3509E416' mount point (current is '/Volumes/MBED')...
[1496740625.14][HTST][INF] starting host test process...
[1496740625.15][CONN][INF] starting connection process...
[1496740625.15][CONN][INF] notify event queue about extra 60 sec timeout for serial port pooling
[1496740625.15][CONN][INF] initializing serial port listener...
[1496740625.15][PLGN][INF] Waiting up to 60 sec for '123602210A4D671D3509E416' serial port (current is '/dev/tty.usbmodem141423')...
[1496740625.15][HTST][INF] setting timeout to: 60 sec
[1496740626.13][SERI][INF] serial(port=/dev/tty.usbmodem141423, baudrate=9600, read_timeout=0.01, write_timeout=5)
[1496740626.13][SERI][INF] reset device using 'default' plugin...
[1496740626.53][SERI][INF] waiting 1.00 sec after reset
[1496740627.54][SERI][INF] wait for it...
[1496740627.54][SERI][TXD] mbedmbedmbedmbedmbedmbedmbedmbedmbedmbed
[1496740627.54][CONN][INF] sending up to 2 __sync packets (specified with --sync=2)
[1496740627.54][CONN][INF] sending preamble 'daf05fa9-7e71-496b-b76e-9fc4fe715a4b'
[1496740627.54][SERI][TXD] {{__sync;daf05fa9-7e71-496b-b76e-9fc4fe715a4b}}
[1496740628.55][CONN][INF] resending new preamble 'aa6416f6-7e8a-49cb-9127-39b4d0cc1c72' after 1.01 sec
[1496740628.55][SERI][TXD] {{__sync;aa6416f6-7e8a-49cb-9127-39b4d0cc1c72}}
[1496740685.27][HTST][INF] test suite run finished after 60.12 sec...
[1496740685.28][CONN][INF] received special even '__host_test_finished' value='True', finishing
[1496740685.29][HTST][INF] CONN exited with code: 0
[1496740685.29][HTST][INF] No events in queue
[1496740685.29][HTST][INF] stopped consuming events
[1496740685.29][HTST][INF] host test result(): None
[1496740685.29][HTST][WRN] missing __exit event from DUT
[1496740685.29][HTST][WRN] missing __exit_event_queue event from host test
[1496740685.29][HTST][ERR] missing __exit_event_queue event from host test and no result from host test, timeout...
[1496740685.29][HTST][INF] calling blocking teardown()
[1496740685.29][HTST][INF] teardown() finished
[1496740685.29][HTST][INF] {{result;timeout}}
mbedgt: checking for GCOV data...
mbedgt: mbed-host-test-runner: stopped and returned 'TIMEOUT'
mbedgt: test case summary event not found
    no test case report present, assuming test suite to be a single test case!
    test suite: mbed-os-tests-integration-basic
    test case: mbed-os-tests-integration-basic
mbedgt: test on hardware with target id: 123602210A4D671D3509E416
mbedgt: test suite 'mbed-os-tests-integration-basic' ................................................. TIMEOUT in 67.11 sec
    test case: 'mbed-os-tests-integration-basic' ................................................. ERROR in 67.11 sec
mbedgt: test case summary: 0 passes, 1 failure
mbedgt: all tests finished!
mbedgt: shuffle seed: 0.3395421590
mbedgt: test suite report:
+---------------------------+-------------------+---------------------------------+---------+--------------------+-------------+
| target                    | platform_name     | test suite                      | result  | elapsed_time (sec) | copy_method |
+---------------------------+-------------------+---------------------------------+---------+--------------------+-------------+
| UBLOX_EVK_ODIN_W2-GCC_ARM | UBLOX_EVK_ODIN_W2 | mbed-os-tests-integration-basic | TIMEOUT | 67.11              | shell       |
+---------------------------+-------------------+---------------------------------+---------+--------------------+-------------+
mbedgt: test suite results: 1 TIMEOUT
mbedgt: test case report:
+---------------------------+-------------------+---------------------------------+---------------------------------+--------+--------+--------+--------------------+
| target                    | platform_name     | test suite                      | test case                       | passed | failed | result | elapsed_time (sec) |
+---------------------------+-------------------+---------------------------------+---------------------------------+--------+--------+--------+--------------------+
| UBLOX_EVK_ODIN_W2-GCC_ARM | UBLOX_EVK_ODIN_W2 | mbed-os-tests-integration-basic | mbed-os-tests-integration-basic | 0      | 1      | ERROR  | 67.11              |
+---------------------------+-------------------+---------------------------------+---------------------------------+--------+--------+--------+--------------------+
mbedgt: test case results: 1 ERROR
mbedgt: completed in 67.88 sec
mbedgt: exited with code 1

[jeromecoutant]

Hi
You are pointing on the top of master branch.
We got several issues since #4294 merge...
Please set mbed-os before this merge, and try again
Thx

[LiyouZhou]

@jeromecoutant can you give me a release version to use?

[LiyouZhou]

@jeromecoutant just tested using 5.4.4, same issue.

[LMESTM]

@LiyouZhou @bridadan reported issue related to some printf. Those debug printf come from spi driver when DEBUG_STDIO is defined. I thought this define should be defined on per file basis - is this defined for your complete project?

[LiyouZhou]

@LMESTM see the newest log, I have re-done this with a clean mbed-os project, no modifications.

[bridadan]

@LiyouZhou I tried to reproduce this issue on an Ubuntu 16.04 VM (Windows 10 host) and I wasn't able to using the latest STLink firmware. My steps were as follows:

mbed import mbed-os-example-blinky
cd mbed-os-example-blinky
mbed test -m UBLOX_EVK_ODIN_W2 -t GCC_ARm -v        # Test completes successfully

Perhaps we should setup a Skype call you so you can walk me through your environment?

[LiyouZhou]

@bridadan ok, i have also verified that it works on ubuntu. So it is a problem with MAC. Can you get hold of anybody in Austin with a MAC to verify this for you?

[bridadan]

@LiyouZhou There's a few folks here who have Macs, I'll try to corner them today and see what I find.

[bridadan]

OK, I was able to reproduce this error on a MAC. It's not a problem with the test tools specifically, it looks like the MAC isn't sending any data to the device. I wrote a simple echo program and I wasn't getting any echoed characters on the MAC, but when I tested on Windows I was able to get some echoed characters back. It will take a little more debugging to figure out where the failure is happening (ex. The MAC isn't sending it at all or ST-Link isn't recognizing the characters)

[bridadan]

So the crazy thing is, I can't reproduce it any more. I tested on two different Mac machines running 10.12.5.

I hooked up my logic analyzer to the ST-Link serial pins and I could see the serial data coming across just fine.

@LiyouZhou Are you able to print form the device just fine using a serial terminal? And can you receive data over that same serial line? If you're still having this problem after trying this then we should Skype since you can reliably reproduce it.

[cmonr]

@bridadan @LiyouZhou Is this still a issue?

[0xc0170]

@bridadan @LiyouZhou Is this still a issue?

Considered as resolved. If not , please provide an update and reopen

[MarceloSalazar]

Reproducing problem on Mac only with latest Stlink
FYI @theotherjimmy @screamerbg

[bridadan]

@MarceloSalazar can you please list the following info about your test:

• What version of Mac OS are you using
• What platform are you using
• What version of STLink is on the board
• Your pip package version are (pip list)
• Can you see serial output from the device using a simple "HelloWorld" example on the device without using greentea?

[MarceloSalazar]

Tested on OSX El Capitan.

Platforms: Nucleo F429, Nucleo L476, Odin W2

SLINK FW: V2J32M22 (latest) and previous (can't find it now)

Pip: (don't have full list right now)

• greentea 1.4.0 (latest) and 1.3.1
• htrun 1.4.1(latest) and 1.3.1

Serial on Blinky (without greentea) works fine. With greentea does not.

@theotherjimmy please comment if there is anything missing, as you have more information to reproduce this.

[bridadan]

Marcelo, the next thing to double check is does RX work on the device, specifically the "Echo back characters you type" example: https://os.mbed.com/handbook/SerialPC#examples

[bcostm]

@schstm to be aware

[MarceloSalazar]

Yes, I confirm RX and echo works well on the platforms.
Interestingly, when running Mbed OS greentea tests with a bootloader merged into the binary, it fails to run the application (the bootloader works well).

The problem seems to be hit when combining STLink + greentea.

I can't tell where exactly the problem is coming from, but it should be 'easy' to reproduce.

[bridadan]

Ok, I don't have a Mac to test on. Perhaps you and I can set up a call where we can remotely debug together?

[bridadan]

@MarceloSalazar, I have not checked the status of this recently, do you know off the top of your head if this is still an issue? If so I can attempt to reproduce the issue (once I find a Mac to test on).

[bridadan]

Spoke with @MarceloSalazar offline, he has not tried this lately with the latest ST-Link.

~Has anyone else been experiencing this? If not I will probably end up closing this.~

@MarceloSalazar said he will try to retest this soon.

[0xc0170]

@MarceloSalazar said he will try to retest this soon.

@MarceloSalazar shall this be closed or?

[MarceloSalazar]

Not yet - please wait a bit ;-)

[MarceloSalazar]

I've had a chance to try this again on my Mac El Capitan.

First, upgraded my NUCLEO_L476RG and DISCO_L476VG to STLink 2.33.25 (latest from ST website).

Then I've run echo tests with GCC (6.3.1), using Mbed OS 5.12.1

mbed test -t GCC_ARM -m NUCLEO_L476RG -n *echo* -vv

Unfortunately, this still fails for both platforms - see log stlink-test-180419.txt

Note, after re-plugging the device over USB and launching the tests, the target responds with [RXD] mbedmbedmbedmbedmbedmbedmbedmbed, but then enters a weird state and the test fails.

The second time I run the test, the target doesn't respond.

[jeromecoutant]

@schstm Do we have some test results with STLink v2.33.25 and MacOs ?

[schstm]

@jeromecoutant the v2.33.25 was tested on MacOS Yosemite (v10.10) but not in the context of this mbed test; it's difficult to figure out where the problem comes from without a detailed knowledge of what the test is doing ? Perhaps understanding from where comes the mbedmbedmbed... string can give a first clue. Is it an echo of something coming from the host or what may trigger the target for sending this ?

[MarceloSalazar]

I continue to see the same issue when testing this on macOS 10.14: Mojave

The mbed test tools use greentea and htrun - you may want to read more about the test framework here:
https://github.com/ARMmbed/mbed-os-tools/tree/master/packages/mbed-host-tests

One way to reproduce this issue is by running the echo test, but any other test will fail, e.g timer.

[schstm]

Studying stlink-test-180419.txt, I firstly noticed some issues for which I don't know the impact afterwards:
[mbed-5295] WARNING: Missing Python modules were not auto-installed.
The Mbed OS tools in this program require the following Python modules: pyusb
HOST: Error! While loading local host test module '/Users/msal/mbed/STlink/stlink-test/mbed-os/TESTS/host_tests/pyusb_basic.py'
HOST: No module named usb.core
Then it looks like the target is alive and running as expected:
[1555583753.88][CONN][RXD] >>> Running case #1: 'Echo server: x16'...
And the issue seems linked to this:
[1555583753.95][SERI][TXD] {{echo_count;16}}
[1555583783.98][HTST][INF] test suite run finished after 30.28 sec...
[1555583783.99][CONN][INF] received special event '__host_test_finished' value='True', finishing.

Unfortunately I'm not familair enough with the test environment in order to figure out what may be the cause for such "__host_test_finished special event", is it coming from a sequence received from the VCP (but not displayed in the trace), or a disconnection at USB level ?

I think it would be interesting to firstly solve the warning about pyusb, in order to ensure all is fine in the usb context for the test, perhaps we may have further clues afterwards

[bridadan]

Hi @schstm, looks like you're running one of the USB stack tests. They have an extra pip module you need to install, which you should be able to do with pip install pyusb.

[MarceloSalazar]

Issue being discussed here as well:
https://forums.mbed.com/t/mbed-greentea-testing-framework-resulting-in-sync-failed-for-all-unit-tests/5609

[ciarmcom]

Thank you for raising this detailed GitHub issue. I am now notifying our internal issue triagers.
Internal Jira reference: https://jira.arm.com/browse/IOTOSM-2225

[ithinuel]

Reproduced with the DISCO_L475_IOT01A on the MacBook Air running macOS Big Sur 11.1 on an Apple M1.

[jeromecoutant]

Hi @ithinuel
Do you have the possibility to sniff USB traffic ?

[ithinuel]

I can sniff it with a logic analyzer (Saleae) or try with wireshark.
I'm not super proficient with MacOS tools, so there may be other options I don't know about.

I've done some extra test I could reliably reproduce by stressing the serial port regardless of the App running of the stm32l475.
I could reproduce with:

• mbed's driver echo test
• mbed's Serial EchoBack snippet (note I fixed a little bug there)
• A non-mbed app (a little rust loopback I can share too if needed)

I plan to install cubemx on the Apple machine and put together another c baremetal loopback that reproduces the issue.

[ithinuel]

The device was free running (no pycod/openocd).
I generated the project with cubeMX. Please find in LoopBack.zip the ICO file.
I added this snippet to handle a simple loopback:

  while (1)
  {
      if (__HAL_UART_GET_FLAG(&huart1, UART_FLAG_RXNE) && __HAL_UART_GET_FLAG(&huart1, UART_FLAG_TXE)) {
          uint8_t buf;
          HAL_UART_Receive(&huart1, &buf, 1, 10);
          HAL_UART_Transmit(&huart1, &buf, 1, 10);
      } else if (__HAL_UART_GET_FLAG(&huart1, UART_FLAG_ORE | UART_FLAG_FE | UART_FLAG_NE | UART_FLAG_PE)) {
          uint8_t dummy;
          HAL_UART_Receive(&huart1, &dummy, 1, 10); // clears error flags
      }
    /* USER CODE END WHILE */
    /* USER CODE BEGIN 3 */
  }

From 5s 764ms 720μs, every PID OUT's data phase are filled with dummy.
I'm not familiar enough with USB to remember which end is sending this dummy but it does not feel like it's an expected packet.

debug_stm32_on_mac_stmcube_fw.zip. (captured with logic 2.3.16)

EDIT: The text I used is the first paragraph of https://www.lipsum.com/. It does contain the word “dummy” but only twice.

[ithinuel]

I did some further investigation and it turns out that “dummy” is the next bit of data that is emitted by the USB host but for some reason the interface chip always NAK it and thus it is resend endlessly by the host.

EDIT: I don't know why the target MCU stopped emitting the echo but that's not relevant for that issue anyway.