Greentea debuging (Blackpill-F411CE)

[JohnK1987]

Hello @mbed-ce/developers,

I'm trying to learn something new and prepare Blackpill-F411CE (for more just Dut) as a regular target. So I ran Greentea with result below

The following tests did not run:
          8 - mbed-hal-crc (Skipped)
         14 - mbed-hal-ospi (Skipped)
         16 - mbed-hal-qspi (Skipped)
         27 - mbed-hal-trng (Skipped)
         32 - mbed-hal-verify-arduino-pinmap (Skipped)
         43 - mbed-platform-crash-reporting (Skipped)
         53 - mbed-platform-stats-cpu (Skipped)
         54 - mbed-platform-stats-heap (Skipped)
         55 - mbed-platform-stats-sys (Skipped)
         56 - mbed-platform-stats-thread (Skipped)
         71 - mbed-connectivity-nfc-eeprom (Skipped)

The following tests FAILED:
          2 - mbed-usb-device-basic (Failed)
         17 - mbed-hal-reset-reason (Failed)
         22 - mbed-hal-sleep (Failed)
         23 - mbed-hal-sleep-manager (Failed)

Ok, I want to debug Greentea mbed-hal-reset-reason now. I followed Debugging-Failing-Greentea-Tests and it seems to be clear to me. However my knowledge seem to be not enough anyway.

If I understand correctly how it does, then according to log below the Host wants to restart the DUT, then wait for its boot and than expect the confirmation of reconnection.

13: [1663528501.01][CONN][INF] found KV pair in stream: {{reason;cleared}}, queued...
13: [1663528501.02][CONN][INF] received special event '__reset', resetting dut
13: [1663528501.02][SERI][INF] reset device using 'default' plugin...
13: [1663528501.28][SERI][INF] waiting 1.00 sec after reset
13: [1663528502.28][SERI][INF] wait for it...
13: [1663528503.29][SERI][TXD] {{__sync;0}}
13: [1663528503.35][CONN][RXD] mbedmbedmbedmbedmbedmbedmbedmbed

If my understanding above is correct, then how the reset from Host side to Dut side is performed please? I found my test keep failing because the reset of the Dut is not performed, but when I do it manually in correct time then the test continue.

[1670966708.39][CONN][INF] found KV pair in stream: {{reason;cleared}}, queued...
[1670966708.40][CONN][INF] received special event '__reset', resetting dut
[1670966708.40][SERI][INF] reset device using 'default' plugin...
[1670966708.66][SERI][INF] waiting 1.00 sec after reset
[1670966709.66][SERI][INF] wait for it...
[1670966710.67][SERI][TXD] {{__sync;0}}
[1670966712.97][CONN][RXD] :131::FAIL: Invalid message key.

Any hints? Thank you

Edit:

• 17 - mbed-hal-reset-reason (Failed) - was caused by someting in my TTL convertor (from aliexpres probably clone of FTDI).
• 22 - mbed-hal-sleep (Failed)
  23 - mbed-hal-sleep-manager (Failed)
  Both was failed because of LP ticker, probably something with RTC module (I do not know). However I found many STM32F4 targets has LP Ticker disabled so I did same.
• 2 - mbed-usb-device-basic (Failed) - was not debuged (my board is broken)

Edit2:
Do not use tou much long wires for connection between debugger and the target. Ideally <= 10cm .

Edit3:
LPTICKER is back in the game. It looks like there were a wrong clock source settings from original source.

BR, Jan

[JojoS62]

Hi Jan,
my experience with this target is that it is hard to connect the debugger because the mbed standard code will keep it in __wfi. It needs a hardware reset, but this line is not on the four pin SWD connector. When you are using a STLink, try to connect the reset pin to the debugger.

[JohnK1987]

Thank you Jojo for your response.
I am using St-link from Nucleo board and NRST pin from its SWD connector is already wired to reset pin of Blackpill. When I hit reset button on the Nucleo, then also Blackpill is restarted.

BR, Jan

[JohnK1987]

Just for clarification. I am able to run the debug mode and also do steps through the code. I have the reset wire connected. So there I have no issue.

BR, Jan

[JohnK1987]

@multiplemonomials any hints?

[multiplemonomials]

Tracing through the host code, I'm pretty sure this function is used to reset the device: https://github.com/ARMmbed/mbed-os-tools/blob/c467d6f1498018669872883a95a8c9c9120d6abd/src/mbed_os_tools/test/host_tests_plugins/module_reset_mbed.py#L106

Looks like it works by sending a break condition over the serial port. Try that out -- if you send a break (Alt-B in TeraTerm), does the chip reset?

[JohnK1987]

Ok Jamie, I will try your suggestion and publish the full log today later.

BR, Jan

[JohnK1987]

Okey @multiplemonomials your suggestion led to the solution.
I tried same test with a standart Nucleo board with positive result. Then I tried your suggestion about the send brake and from a serial terminal and it also works, but does not work with the Blackpill. I had the Blackpill UART connected via a TTL convertor with FTDI chip (probably a clone) and that seems to be the rootcause. I changed the TTL convertor with ST-Link VCP and it is working now.

1/1 Test #17: mbed-hal-reset-reason ............   Passed   11.80 sec

I will continue with the rest failed tests.

Thank you
BR, Jan

[JohnK1987]

Hmm, I do not understand what happened. Blackpill had an issue time to time and I was not able connect to it. I thought it was about bad contact of wires between Blackpill and ST-Link. But I am not able to connect to it anymore... MCU seems to be dead.

BR, Jan

[JohnK1987]

Latest information are in edits of original topic above.
And finally #123

BR, Jan

[JojoS62]

Try the sequence hold boot button, press reset, release boot button.

…

Am 17.12.2022 um 17:14 schrieb JohnK1987 ***@***.***>:  Hmm, I do not understand what happened. Blackpill had an issue time to time and I was not able connect to it. I thought it was about bad contact of wires between Blackpill and ST-Link. But I am not able to connect to it anymore... MCU seems to be dead. BR, Jan — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are on a team that was mentioned.

[JohnK1987]

The new board does not have any Mbed program uploaded it was still with default example from delivery.
But yesterday I connect the STM32CUBE programmer via DFU and I was able to make Full Chip Erase. So now are both targets clean, but it is not working anyway.

Give me a time Jojo, I will share, but currently make a chaos...

BR, Jan

[JohnK1987]

@JojoS62
I had to rework my project, so I hope I haven't forgotten anything - https://github.com/JohnK1987/mbed-os/tree/BlackPill_F411CE

BR, Jan

[JohnK1987]

Ok I got it... OMG so stupid thing!

Yesterday night I found this topic , but I had no time to test it until now.

I used 20cm long wires and times to times the connection failed. I thought it was about bad contact of wires between Blackpill and ST-Link, so I changed the wires to wires with better contacts, but much longer (40cm). And this is the root cause, too much long wires...

I wasted too much time with this, but it is good experience and valuable information for future Blackpill board page.

@JojoS62 thank for your effort to help to open this nut.

Merry Christmas

BR, Jan

[JojoS62]

Great. I had also bad luck with cheap DuPont wires, even a broken wire inside a cable.
I will stay on this topic and try also your branch. I’ve got my custom blackpill target also running, but I’m not sure how to use it with Mbed tests.

[JohnK1987]

I did a simple fast note for my self according to Jamie's guide. That helps me I not need to look to the guide every time :)

Greentea run:
(first two points can be skipped if you want run test from existing project)

1. Create a new local repo
   cmd: git init
2. Clone MbedOS
   cmd: git submodule add --depth 1 https://github.com/mbed-ce/mbed-os.git mbed-os
3. Move into MbedOS folder
   cmd: cd mbed-os
4. Check
   cmd: python -m pip install -r tools/requirements.txt
   cmd: python -m pip install -r tools/requirements-ci-build.txt
5. Create build directory
   cmd: mkdir BUILD_GT_BLACKPILL_F411CE && cd BUILD_GT_BLACKPILL_F411CE
6. Run pre-build
   cmd: cmake .. -GNinja -DMBED_TARGET=BLACKPILL_F411CE -DCMAKE_BUILD_TYPE=Develop -DMBED_BUILD_GREENTEA_TESTS=ON -DMBED_GREENTEA_SERIAL_PORT=COM3 -DUPLOAD_METHOD=STM32CUBE
7. Compile
   cmd: ninja
8. Run full GT
   cmd: ctest . --output-on-failure
9. If you want to run a specific test then you need run a name of specific test, for example
   cmd: ctest -V -R mbed-hal-common-tickers

Debug GT:
(separate terminals)

• In terminal 1. run flash of requested test
  cmd: ninja flash-mbed-hal-common-tickers
• In terminal 2. run GDB server from build folder
  cmd: ninja gdbserver
• In terminal 3. run debug
  • connect test with GDB server
    cmd: ninja debug-mbed-hal-common-tickers
  • there set break point to main or a function form main, see main of current test
    cmd: b ticker_interrupt_test
    cmd: continue
• In terminal 1. run requested test and then look for a line what start with mbedhtrun and make copy of that line and later add --skip-reset at the end of line. For example - mbedhtrun --skip-flashing -p COM3 -e C:/Users/USER/MbedCE_GreenTea/mbed-os/hal/tests/TESTS/mbed_hal/common_tickers/../../ticker_interrupt_test -m BLACKPILL_F411CE --baud-rate=115200 --skip-reset
• Then just swith betweeen terminals 1. and 3.

BR, Jan

[JojoS62]

I'm trying to run the greentea tests with a custom target. As a startpoint I have used the mbed-ce-hello-world project and added the custom target, that works. But I can't compile the mbed-os tests with this target.

This is my CMakeLists.txt:

#
# Mbed CE Hello World Project
#
cmake_minimum_required(VERSION 3.19)
cmake_policy(VERSION 3.19)

# Initialize Mbed OS build system. 
# Note: This block must be before the project() call.
set(MBED_APP_JSON_PATH mbed_app.json)
set(CUSTOM_TARGETS_JSON_PATH custom_targets/custom_targets.json) # If you need a custom target, use this line to specify the custom_targets.json
set(MBED_ENABLE_OS_INTERNAL_TESTS TRUE)
set(MBED_BUILD_GREENTEA_TESTS TRUE)
set(MBED_GREENTEA_SERIAL_PORT "/dev/ttyACM0")
set(STM32CUBE_UPLOAD_ENABLED TRUE)
set(UPLOAD_METHOD "STM32CUBE")
set(CMAKE_BUILD_TYPE "Develop")
set(MBED_TARGET "WEACT_F411CE")
set(MBED_ENABLE_TESTING TRUE)

include(mbed-os/tools/cmake/app.cmake) # Load Mbed CE toolchain file and basic build system

# If you need any custom upload method configuration for your target, do that here

add_subdirectory(custom_targets)
add_subdirectory(mbed-os) # Load Mbed OS build targets.  Must be added before any other subdirectories

project(MbedCEHelloWorld)
# add_executable(HelloWorld main.cpp)
# target_link_libraries(HelloWorld mbed-os) # Can also link to mbed-baremetal here
# mbed_set_post_build(HelloWorld HelloWorld stm32f411xe.ld) # Must call this for each target to set up bin file creation, code upload, etc
mbed_finalize_build()

The tests are compiling, but linking fails.
@multiplemonomials should it be possible by modifiying the existing switches?

it works when I disable this if():

mbed-os/tools/cmake/mbed_set_linker_script.cmake

Line 91 in 91d1cb8

if(MBED_IS_STANDALONE)

We need something to set 'standalone' when used in test project.

And the tests are not yet running with ctest . --output-on-failure
The DartConfiguration.tcl file is not generated by the cmake run.

[JojoS62]

thanks, no problem. The compiling works, so it looks like it is half way solved. I could not yet find where this tcl file is created. But I will continue on this also next week.

[multiplemonomials]

Maybe the enable_testing() CMake function is not being called?

[JojoS62]

I don't see such a function, I have added

set(MBED_ENABLE_TESTING ON)

but it changes nothing,

I see that tests are built, e.g.:

-- built: /home/jojo/projects/mbed-ce-hello-world/build/GT_BLACKPILL_F411CE/mbed-os/rtos/tests/TESTS/mbed_rtos/malloc/mbed-rtos-malloc.bin
-- built: /home/jojo/projects/mbed-ce-hello-world/build/GT_BLACKPILL_F411CE/mbed-os/rtos/tests/TESTS/mbed_rtos/malloc/mbed-rtos-malloc.hex
| Module                   |     .text |    .data |     .bss |
|--------------------------|-----------|----------|----------|
| CMakeFiles/mbed-os.dir   | 24044(+0) |  440(+0) | 7585(+0) |
| [fill]                   |   154(+0) |    6(+0) |   32(+0) |
| [lib]/c.a                |  6044(+0) | 1344(+0) |  373(+0) |
| [lib]/client_userio.a    |  1484(+0) |   56(+0) |    8(+0) |
| [lib]/gcc.a              |   764(+0) |    0(+0) |    0(+0) |
| [lib]/mbed-greentea-io.a |    72(+0) |    0(+0) |    0(+0) |
| [lib]/mbed-unity.a       |   796(+0) |    0(+0) |  160(+0) |
| [lib]/mbed-utest.a       |  3372(+0) |   13(+0) |  201(+0) |
| [lib]/misc               |   264(+0) |    4(+0) |   25(+0) |
| [lib]/stdc++.a           |     0(+0) |    0(+0) |    0(+0) |
| rtos/tests               |   694(+0) |    1(+0) |  184(+0) |
| Subtotals                | 37688(+0) | 1864(+0) | 8568(+0) |
Total Static RAM memory (data + bss): 10432(+0) bytes
Total Flash memory (text + data): 39552(+0) bytes

but ctest is not finding these. Maybe it is more ctest problem?

jojo@sn-1:~/projects/mbed-ce-hello-world/build/GT_BLACKPILL_F411CE/mbed-os$ ctest . --output-on-failure
Test project /home/jojo/projects/mbed-ce-hello-world/build/GT_BLACKPILL_F411CE/mbed-os
No tests were found!!!
jojo@sn-1:~/projects/mbed-ce-hello-world/build/GT_BLACKPILL_F411CE/mbed-os$ ctest -V -R mbed-hal-common-tickers
UpdateCTestConfiguration  from :/home/jojo/projects/mbed-ce-hello-world/build/GT_BLACKPILL_F411CE/mbed-os/DartConfiguration.tcl
UpdateCTestConfiguration  from :/home/jojo/projects/mbed-ce-hello-world/build/GT_BLACKPILL_F411CE/mbed-os/DartConfiguration.tcl
Test project /home/jojo/projects/mbed-ce-hello-world/build/GT_BLACKPILL_F411CE/mbed-os
Constructing a list of tests
Updating test list for fixtures
Added 0 tests to meet fixture requirements
Checking test dependency graph...
Checking test dependency graph end
No tests were found!!!

the file DartConfiguration.tcl does not exist. Should it be built by the cmake run or is it generated by ctest?

[multiplemonomials]

This function is built into cmake: https://cmake.org/cmake/help/latest/command/enable_testing.html

[JojoS62]

the reason is here:

mbed-os/CMakeLists.txt

Line 17 in afba4e1

if(CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR)

this test evaluates to false and sets MBED_IS_STANDALONE = FALSE, and then MBED_BUILD_GREENTEA_TESTS = FALSE.
When I force MBED_IS_STANDALONE to TRUE, then the tests are built. I need to change to mbed-os dir and ctest is running.