mbed-ce / mbed-os Goto Github PK

This project forked from armmbed/mbed-os

Arm Mbed OS is a platform operating system designed for the internet of things

License: Other

C 97.04% C++ 1.77% Assembly 0.68% HTML 0.01% Python 0.30% CMake 0.15% Makefile 0.03% Shell 0.01% XSLT 0.01% Batchfile 0.01% Perl 0.01% Tcl 0.01% Dockerfile 0.01%

mbed-os's Introduction

Mbed OS Community Edition

Arm Mbed OS is an open source embedded operating system designed specifically for the "things" in the Internet of Things. It includes all the features you need to develop a connected product based on an Arm Cortex-M microcontroller, including security, connectivity, an RTOS and drivers for sensors and I/O devices.

Mbed OS provides a platform that includes:

Security foundations.
Cloud management services.
Drivers for sensors, I/O devices and connectivity.

This is Mbed OS Community Edition (CE), a fork focused on improving the build system and tooling, fixing bugs, and keeping maintenance going after ARM's step back from the Mbed project.

License and contributions

The software is provided under the Apache-2.0 license. Contributions to this project are accepted under the same license. Please see contributing.md for more information.

This project contains code from other projects. The original license text is included in those source files. They must comply with our license guide.

Folders containing files under different permissive license than Apache 2.0 are listed in the LICENSE file.

Getting started for developers

To start a new project that uses Mbed CE, see the setup guide here.

We have a developer website for asking questions, engaging with others, finding information on boards and components, using an online IDE and compiler, reading the documentation and learning about what's new and what's coming next in Mbed OS.

Additionally, the discussions page on this repo can be used for proposing and discussing specific code changes.

Documentation

Mbed CE Docs

For the Mbed CE code-level documentation (Doxygen), see here. For an auto-generated listing of target boards supported by Mbed, and the drivers & features each target supports, see the targets index here and the drivers index here.

Mbed CE is still working on more complete documentation infrastructure. Eventually, we hope to migrate all of the docs and examples as well. However, for now, see below to access those on the original Mbed OS docs site.

Original ARM Mbed OS Docs

For more information about Mbed OS, please see the published Mbed OS documentation. It includes general overview information, step-by-step tutorials, porting information and background reference materials about our architecture and tools.

mbed-os's People

Contributors

Stargazers

Watchers

Forkers

wubaojun1982 mrbubble62 ddc-ndrs wwatson4506 leka jancotipsarevic hoelej qwertyquerty johnk1987 macronix wdx04 timideatech

mbed-os's Issues

Make version different from Mbed OS

The Mbed version info is stored in this file: https://github.com/mbed-ce/mbed-os/blob/master/platform/include/platform/mbed_version.h

We should probably change it so that it's different from mainline Mbed. Since there are some breaking changes in Mbed CE (and others yet to be made, like #13), should we change it to 7.0.0? Or should we change it to like 6.99 until the breaking changes are mostly over with, and then change it to 7.0.0?

Also, we should fix the "99 is default value for development version" comments in that header file, they are not correct.

Import mbed-cmake's debug configuration generator for VS Code and CLion

I didn't add this in my initial upload/debug support PR (#7) to keep it simpler. But it would be good to copy these files/code sections over from mbed-cmake:
https://github.com/USCRPL/mbed-cmake/blob/master/cmake/VSCodeConfigGenerator.cmake
https://github.com/USCRPL/mbed-cmake/blob/master/cmake/CLionConfigGenerator.cmake
https://github.com/USCRPL/mbed-cmake/blob/ba2c51e368c078fa7121a46e54c122e8a88e1c4e/cmake/MbedExecutable.cmake#L100
https://github.com/USCRPL/mbed-cmake/blob/ba2c51e368c078fa7121a46e54c122e8a88e1c4e/mbed-cmake.cmake#L38

CMake should invoke `mbedtools configure` automatically

It's pretty annoying that, currently, users must manually run mbedtools configure when they first create a build dir and when they change their mbed_app.json files. We can do better -- cmake should be smart enough to execute this command itself. This means that instead of users providing MBED_CONFIG_PATH from the top-level CMakeLists, they would provide MBED_TARGET, MBED_APP_JSON_PATH, and MBED_CUSTOM_TARGETS_JSON_PATH. CMake would then invoke mbedtools configure itself and include the resultant file.

Note that there is actually a somewhat difficult part of this: to prevent spurious rebuilds, CMake needs to be smart enough to only invoke this command when either mbed_app.json, custom_targets.json, or the mbedtools command line actually changes. This means that it needs to look at the timestamps of the json files (or something) and compare them to the last configuration run time (which could be stored in the cache).

Note: We should also detect if the user tries to change the MBED_TARGET and fail with an error, because that just won't do.

Move "hidden" storage docs into mbed-os-docs repo

There's a lot of useful documentation about the storage classes in the Mbed OS source tree here: https://github.com/mbed-ce/mbed-os/tree/master/storage/docs

But since it's there, it won't get published as part of Doxygen docs or as part of the website. We need to relocate it to somewhere it will be seen. Maybe the best option is to merge it into the existing doxygen docs.

Serial corruption on STM32L4 at 115200 baud

It seems like the STM32L4 is experiencing quite serious corruption on its UART transmissions when run at 115200 baud. This is enough to make a few test cases out of each run fail due to missed control messages. Need to look into what's causing this

Custom Target + BLE - Link step failing

Creating an issue for easier tracking. I've been investigating but with no luck :(

Discussed in #136

^{Originally posted by ladislas February 20, 2023}
I'm in the process of moving from the old USCRPL/mbed-cmake to mbed-ce

I've managed to make everything compile but the link step is failing with a lot of undefined reference to __HeapLimit'

/opt/homebrew/Cellar/arm-gcc-bin@10/10.3-2021.10_1/bin/../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/bin/ld: extern/mbed-os/connectivity/FEATURE_BLE/libraries/libmbed-ble-cordio.a(BLEInstanceBaseImpl.cpp.obj): in function `hci_mbed_os_drv_write':
/Users/ladislas/dev/leka/LekaOS/extern/mbed-os/connectivity/FEATURE_BLE/source/cordio/source/BLEInstanceBaseImpl.cpp:83: undefined reference to `ble_cordio_get_hci_driver()'
/opt/homebrew/Cellar/arm-gcc-bin@10/10.3-2021.10_1/bin/../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/bin/ld: extern/mbed-os/connectivity/FEATURE_BLE/libraries/libmbed-ble-cordio.a(BLEInstanceBaseImpl.cpp.obj): in function `hci_mbed_os_start_reset_sequence':
/Users/ladislas/dev/leka/LekaOS/extern/mbed-os/connectivity/FEATURE_BLE/source/cordio/source/BLEInstanceBaseImpl.cpp:89: undefined reference to `ble_cordio_get_hci_driver()'
/opt/homebrew/Cellar/arm-gcc-bin@10/10.3-2021.10_1/bin/../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/bin/ld: extern/mbed-os/connectivity/FEATURE_BLE/libraries/libmbed-ble-cordio.a(BLEInstanceBaseImpl.cpp.obj): in function `hci_mbed_os_handle_reset_sequence':
/Users/ladislas/dev/leka/LekaOS/extern/mbed-os/connectivity/FEATURE_BLE/source/cordio/source/BLEInstanceBaseImpl.cpp:103: undefined reference to `ble_cordio_get_hci_driver()'
/opt/homebrew/Cellar/arm-gcc-bin@10/10.3-2021.10_1/bin/../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/bin/ld: extern/mbed-os/connectivity/FEATURE_BLE/libraries/libmbed-ble-cordio.a(BLEInstanceBaseImpl.cpp.obj): in function `ble::impl::BLEInstanceBase::deviceInstance()':
/Users/ladislas/dev/leka/LekaOS/extern/mbed-os/connectivity/FEATURE_BLE/source/cordio/source/BLEInstanceBaseImpl.cpp:145: undefined reference to `ble_cordio_get_hci_driver()'
/opt/homebrew/Cellar/arm-gcc-bin@10/10.3-2021.10_1/bin/../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/bin/ld: extern/mbed-os/CMakeFiles/mbed-os.dir/platform/source/mbed_retarget.cpp.obj: in function `_sbrk':
/Users/ladislas/dev/leka/LekaOS/extern/mbed-os/platform/source/mbed_retarget.cpp:1528: undefined reference to `__HeapLimit'
/opt/homebrew/Cellar/arm-gcc-bin@10/10.3-2021.10_1/bin/../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/bin/ld: extern/mbed-os/CMakeFiles/mbed-os.dir/cmsis/device/rtos/TOOLCHAIN_GCC_ARM/mbed_boot_gcc_arm.c.obj: in function `software_init_hook':
/Users/ladislas/dev/leka/LekaOS/extern/mbed-os/cmsis/device/rtos/TOOLCHAIN_GCC_ARM/mbed_boot_gcc_arm.c:52: undefined reference to `__StackLimit'
/opt/homebrew/Cellar/arm-gcc-bin@10/10.3-2021.10_1/bin/../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/bin/ld: /Users/ladislas/dev/leka/LekaOS/extern/mbed-os/cmsis/device/rtos/TOOLCHAIN_GCC_ARM/mbed_boot_gcc_arm.c:52: undefined reference to `__StackTop'
/opt/homebrew/Cellar/arm-gcc-bin@10/10.3-2021.10_1/bin/../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/bin/ld: /Users/ladislas/dev/leka/LekaOS/extern/mbed-os/cmsis/device/rtos/TOOLCHAIN_GCC_ARM/mbed_boot_gcc_arm.c:52: undefined reference to `__HeapLimit'

it seems related to BLE/Cordio

We are using BLE with mbed-bluenrg-ms

Any idea what I might be doing wrong?

enable manual settings for launch.json for debugging

I ran also into the problem #25 when starting to debug my F746 using JLink upload. After starting the debugger, it halted the cpu somewhere but did not reset. A manual reset with 'interrupt' and 'mon reset' was possible, but this not conveniant. I prefer also that a flash code is perfomed when debugging is startet (with "request": "launch").

It also looks like the behaviour with the internal servertypes is working faster and better, the servertype 'external' gets different settings. E.g., I have added my manual configuration to launch.json:

{
    "configurations": [
		{
			"type": "cortex-debug",
			"name": "Connect to GDB HSDTriggerController NUCLEO_F746ZG Debug",
			"executable": "D:/Projects/Sn/LocalGit/Mbed-CE/Test-F746/build/MyProgram.elf",
			"cwd": "${workspaceRoot}",
			"gdbPath": "C:/Program Files (x86)/GNU Arm Embedded Toolchain/10 2021.10/bin/arm-none-eabi-gdb.exe",
			"objdumpPath": "C:/Program Files (x86)/GNU Arm Embedded Toolchain/10 2021.10/bin/arm-none-eabi-objdump.exe",
			"servertype": "external",
			"gdbTarget": "localhost:23331",
			"request": "attach"
		},
		{
			"type": "cortex-debug",
			"name": "debug JLink",
			"executable": "D:/Projects/Sn/LocalGit/Mbed-CE/Test-F746/build/MyProgram.elf",
			"cwd": "${workspaceRoot}",
			"servertype": "jlink",
			"device": "STM32F746ZG",
			"runToEntryPoint": "main",
			"request": "launch"
		}
	]
}

The difference is that the mcu is halted, a download and reset is performed and the target runs to the given symbol 'main'.
I have found the mbed_ide_debug_cfg_generator.cmake and UploadMethodManager.cmake where the launch.json is written, but don't quite understand all of the magic that ninja brings in.

How can we handle to keep existing manual entries in launch.json? I guess some upload method 'custom' or 'manual' could leave the contents of launch.json untouched. Modifying just the created entry looks difficult.

Another difference with the servertype jlink is also that the disconnect works without stopping the target. The symbols for stop and disconnect look swapped, but that is maybe a bug in cortex-debug.

I can try to use STMCubeLink for debugging again, but with F7 the problem was that a single step always runs into a Timer Interrupt. That makes debugging nearly impossible. The JLink software changes some debug registers in the MCU to fix this, the STLink doesn't.

Include could not find requested file: UploadMethodJ-Link

Hi.

Following your guide for VSCode here: https://github.com/mbed-ce/mbed-os/wiki/Project-Setup:-VS-Code I have an error while running "CMake: Set Build Target" step (as well as when I try to build project anyway).

Error is:

[main] Unable to determine what CMake generator to use. Please install or configure a preferred generator, or update settings.json, your Kit configuration or PATH variable. Error: No usable generator found.

I have installed all required components (toolchain, vscode extensions, tools, etc).

Kit scanning detected my GCC 10.3.1 arm-none-eabi toolchain correctly.

cmake-variants.yaml I am using is following:

buildType:
  default: Develop
  choices:
    Develop:
      short: Develop
      long: Emit debug information but also optimize
      buildType: Develop
    Debug:
      short: Debug
      long: Emit debug information and don't optimize
      buildType: Debug
    Release:
      short: Release
      long: Optimize generated code
      buildType: Release
board:
  default: DISCO_L475VG_IOT01A
  choices:
    DISCO_L475VG_IOT01A:
      short: DISCO_L475VG_IOT01A
      settings:
        MBED_TARGET: DISCO_L475VG_IOT01A
        UPLOAD_METHOD: J-Link

Any hint?

Thanks!

Clean up Doxygen warnings

#45 added a Doxygen workflow, but running doxygen locally shows there are a great deal of warnings printed from various docs that are not correct, e.g. broken links and undocumented parameters. We need to go through and clean those up. Bonus points for setting the CI to then fail if there are any new warnings added.

Add notes to linking to libraries

Regular mbed-cli will automatically link to libraries based on what you include, while with mbed-tools (which mbed-ce) uses you have to do something like 'target_link_libraries(MyProgram PRIVATE mbed-os mbed-storage-qspif mbed-usb-msd mbed-storage-littlefs-v2)' to get modules linked including include directories.

This is worth mentioning somewhere I think.

Memap prints "unknown object name found in GCC map file"

I see a lot of these in the build output on the CI server RPi

Unknown object name found in GCC map file: libmbed-nucleo-f429zi-lib.a(rtc_api.c.obj)
Unknown object name found in GCC map file: libmbed-nucleo-f429zi-lib.a(serial_api.c.obj)
Unknown object name found in GCC map file: libmbed-os.a(mbed_error.c.obj)
Unknown object name found in GCC map file: libmbed-os.a(mbed_rtos_rtx.c.obj)
Unknown object name found in GCC map file: libmbed-nucleo-f429zi-lib.a(serial_device.c.obj)
Unknown object name found in GCC map file: libmbed-nucleo-f429zi-lib.a(serial_api.c.obj)
Unknown object name found in GCC map file: libmbed-nucleo-f429zi-lib.a(us_ticker.c.obj)

The upload method - NONE is not working

Hello,

@multiplemonomials I found an issue with the upload method - NONE

[main] Configuring project: MbedCE_Testerino 
[proc] Executing command: "C:\Program Files\CMake\bin\cmake.EXE" --no-warn-unused-cli -DMBED_TARGET:STRING=Wio_H725AE -DUPLOAD_METHOD:STRING=STM32CUBE -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE -DCMAKE_BUILD_TYPE:STRING=Debug "-DCMAKE_C_COMPILER:FILEPATH=C:\Program Files (x86)\Arm GNU Toolchain arm-none-eabi\11.3 rel1\bin\arm-none-eabi-gcc.exe" "-DCMAKE_CXX_COMPILER:FILEPATH=C:\Program Files (x86)\Arm GNU Toolchain arm-none-eabi\11.3 rel1\bin\arm-none-eabi-g++.exe" -SC:/Users/USER/MbedCE/MbedCE_Testerino -Bc:/Users/USER/MbedCE/MbedCE_Testerino/build -G Ninja
[cmake] Not searching for unused variables given on the command line.
[cmake] -- Mbed: Loading default upload method configuration from targets/upload_method_cfg/Wio_H725AE.cmake
[cmake] -- Mbed: Detected VS Code IDE, will generate VS Code debug configurations
[cmake] -- Mbed: Not building any Mbed OS tests.
[cmake] -- Located STM32CubeIDE: C:/ST/STM32CubeIDE_1.10.1/STM32CubeIDE
[cmake] -- Mbed: Code upload and debugging enabled via upload method STM32CUBE
[cmake] -- Configuring done
[cmake] -- Generating done
[cmake] -- Build files have been written to: C:/Users/USER/MbedCE/MbedCE_Testerino/build
[variant] Loaded new set of variants
[main] Configuring project: MbedCE_Testerino 
[proc] Executing command: "C:\Program Files\CMake\bin\cmake.EXE" --no-warn-unused-cli -DMBED_TARGET:STRING=Wio_H725AE -DUPLOAD_METHOD:STRING=NONE -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE -DCMAKE_BUILD_TYPE:STRING=Debug "-DCMAKE_C_COMPILER:FILEPATH=C:\Program Files (x86)\Arm GNU Toolchain arm-none-eabi\11.3 rel1\bin\arm-none-eabi-gcc.exe" "-DCMAKE_CXX_COMPILER:FILEPATH=C:\Program Files (x86)\Arm GNU Toolchain arm-none-eabi\11.3 rel1\bin\arm-none-eabi-g++.exe" -SC:/Users/USER/MbedCE/MbedCE_Testerino -Bc:/Users/USER/MbedCE/MbedCE_Testerino/build -G Ninja
[cmake] Not searching for unused variables given on the command line.
[cmake] -- Mbed: Loading default upload method configuration from targets/upload_method_cfg/Wio_H725AE.cmake
[cmake] -- Mbed: Detected VS Code IDE, will generate VS Code debug configurations
[cmake] -- Mbed: Not building any Mbed OS tests.
[cmake] CMake Error at mbed-os/tools/cmake/mbed_ide_debug_cfg_generator.cmake:176 (list):
[cmake]   list GET given empty list
[cmake] Call Stack (most recent call first):
[cmake]   mbed-os/tools/cmake/mbed_target_functions.cmake:193 (mbed_finalize_ide_debug_configurations)
[cmake]   CMakeLists.txt:20 (mbed_finalize_build)
[cmake] 
[cmake] 
[cmake] -- Configuring incomplete, errors occurred!
[cmake] See also "C:/Users/USER/MbedCE/MbedCE_Testerino/build/CMakeFiles/CMakeOutput.log".
[cmake] See also "C:/Users/USER/MbedCE/MbedCE_Testerino/build/CMakeFiles/CMakeError.log".
[proc] The command: "C:\Program Files\CMake\bin\cmake.EXE" --no-warn-unused-cli -DMBED_TARGET:STRING=Wio_H725AE -DUPLOAD_METHOD:STRING=NONE -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE -DCMAKE_BUILD_TYPE:STRING=Debug "-DCMAKE_C_COMPILER:FILEPATH=C:\Program Files (x86)\Arm GNU Toolchain arm-none-eabi\11.3 rel1\bin\arm-none-eabi-gcc.exe" "-DCMAKE_CXX_COMPILER:FILEPATH=C:\Program Files (x86)\Arm GNU Toolchain arm-none-eabi\11.3 rel1\bin\arm-none-eabi-g++.exe" -SC:/Users/USER/MbedCE/MbedCE_Testerino -Bc:/Users/USER/MbedCE/MbedCE_Testerino/build -G Ninja exited with code: 1

I believe it is related to changes from #129 and I think it is just about an If, but I am blind probably, sorry.

BR, Jan

Custom .vscode/launch.json overridden by mbed-ce

We already have a .vscode/launch.json file that we use for openOCD and LLDB for unit tests.

When configuring the project with CMake, the file is overridden and emptied.

Is there a way to avoid that?

Create guide + API for custom targets with source files

Currently, custom target support in Mbed CE is incomplete and we need to finish it out.

There are basically three types of custom targets:

Custom targets with configuration settings only (in custom_targets.json)
Custom targets which add additional source files
Custom targets which add source files and override existing Mbed sources

Currently, the first type is supported properly, and the second type should work (by defining your own CMake target matching the custom target name), but has not been tested yet. However, the third type is not currently possible.

First of all, we need to create a new CMake function, something like

mbed_remove_source_files_from_target()

This will enable the third type of target to be created.

Additionally, we need to create a comprehensive wiki page that explains how to create custom targets. This should cover both how to write the custom_targets.json (this has been a pain point for me in the past!), and how to set up the CMake stuff so that the custom target works.

Make json files json5

JSON5 introduces some really nice quality of life improvements for JSON files, including trailing commas (yes!) and the ability to have comments (yaaaaaasssss!). We should change the mbed-tools python package (would probably need to make a fork) to parse JSON files (mbed_app.json, mbed_lib.json, targets.json) with a json5 parser.

STM32 I2Cv2 HAL: i2c_stop() silently fails, preventing single-byte I2C from operating correctly

I've been working on a test program that uses Mbed boards to talk to a real EEPROM on a board. When I tried it, I immediately saw weird results coming out of the I2C transactions. For context, this is an issue I've been trying to track down for a while (originally saw it over 3 years ago!), and it's been awfully intermittent, but it seems like it reproduces reliably here.

Basically, this is what the I2C transaction with the EEPROM is supposed to look like:

However, when I tested it, I got this:

Essentially, after the first data byte is transmitted, there's a long pause, then a ninth SCL pulse, then no STOP condition at all. We should just see a final SCL pulse Furthermore, the next I2C operation never even occurs.

Enabling DEBUG_STDIO in i2c_api.c and adding some prints to the i2c_stop() function makes the source of the problem fairly clear:

[1664344852.31][CONN][RXD] timeout in i2c_stop waiting for I2C_FLAG_TXIS
[1664344852.34][CONN][RXD] TIMEOUT or error in i2c_read

Basically, it gets to the i2c_stop() function and hits this line. It never gets the TXIS flag, so then it times out. I believe that this leaves the peripheral in a bad state (since it does not send a stop condition and it never gets to i2c_sw_reset(obj);), causing subsequent I2C operations to also fail.

This issue has been exacerbated by the bad situation with return codes from i2c_stop(). The C API function has one, but it it's undocumented 🤦 , and seems like the designers assumed I2C::stop() could not fail, so the C++ API function simply discards the return code from the lower layer. I'm pretty sure this function has been failing since it was first introduced, but no one ever noticed because of this.

Back to the main question: why doesn't the TXIS flag that it's looking for set? This one took a bit of work, but I believe it's answered by the following diagram from the STM32L4 reference manual:

Basically, the TXIS flag is an indicator that the Tx register is ready to receive another byte to be shifted out. It sets as soon as the current byte starts to be shifted out and the TXDR register empties. But, crucially, as shown above, it doesn't set after the last byte in a transfer is shifted out! This is because the hardware knows that you aren't planning to shift out another byte so it doesn't want to interrupt you needlessly.

Now, if you look here, you can see that the hardware is being configured with a transfer size of 1 (necessary since we don't know the size and want to reload a new byte each time). Crucially, this means that every byte is the "last" byte, so the TXIS flag never sets!

Instead, what this code should be doing is looking at the TCR flag, which sets when the current transfer completes. It also needs to be waiting BYTE_TIMEOUT instead of FLAG_TIMEOUT, because we might potentially need to wait for an entire byte to transmit.

Indeed, if I make these changes, the errors go away, and we get a much better looking waveform:

Does mbed-ce supports development boards which have been supported by mbed-os?

https://os.mbed.com/platforms/
the development boads supported by mbed-os has 176 boards, such as
https://os.mbed.com/platforms/ST-Nucleo-G474RE/
https://os.mbed.com/platforms/ST-Nucleo-L4R5ZI-P/
and so on.

Use of static libraries and whole-archive causes duplicated symbols

Discovered this while working on #55. Several months ago, I set up the build system to use a combination of STATIC libraries, linking with -Wl,--whole-archive, and -Wl,--allow-multiple-definition so that weak symbols would be resolved correctly. However, this turns out to cause ld to duplicate some/all symbols linked in this manner. Code still works, but ends up using significantly more memory than it should since everything in Mbed OS gets included twice in the binary.

Full details can be read on the ld bug I filed: https://sourceware.org/bugzilla/show_bug.cgi?id=29660

We need to retool everything to use OBJECT libraries instead of STATIC ones.

Linking netsocket pulls in too many dependencies

With how the CMake build system is currently set up, if you link the netsocket library, you get:

lwipstack (plus PPP)
nanostack (plus CoAP dependencies)
Ethernet MAC driver, if one exists for your target (mbed-emac)
10+ different external cellular module drivers (via mbed-cellular)
several different external wifi module drivers (via mbed-wifi)

This seems a little excessive considering that most people will probably only be interested in one IP stack plus either ethernet or cellular. Maybe we should create a config option (or find an existing one) that selects between LwIP and Nanostack. Also, maybe we could hide the cellular and wifi drivers behind COMPONENT_ labels so they aren't enabled by default.

Need better handling for unsupported I2C frequencies

Currently, some Mbed devices support any I2C frequency, while other ones only support a limited subset. Furthermore, some of the HAL implementations (nRF52) round the frequency that you pass in if it's not supported, while others (STM32) generate an assertion failure. This behavior is very obtuse to a user and needs to be standardized. In a perfect world, all HALs should support arbitrary I2C frequencies. If that's not feasible, we should have some way for code to check what frequency actually ended up getting set (and update docs accordingly).

MIMXRT106x: LPTicker does not work

Running tests, I've found that mbed's LPTicker implementation does not seem to work on MIMXRT106x processors. Even though the 106x is supposed to be register compatible with the 105x, Mbed's implementation generates a hard fault on this processor only.

I spent an hour or so debugging, and wasn't able to get anywhere. It seems like something really spooky was happening, where the processor was jumping over the end of one of the fsl_dcdc.c functions and continuing into the next one? But it's also possible that this was a debugger issue, or that the nature of the error was being distrubed by the debugger. A lot of MCUs don't allow the debugger to function properly once they enter low-power mode...

It's also worth noting that if you import the "power_mode_switch_bm" example project in MCUXpresso, there is a new and different version of the lpm.c and fsl_dcdc.c code present. I'm unsure if this is an update for the MIMRT106x and 105x, or just the 106x. I tried importing this version just to see and it seemed to have another "random hard fault" type issue.

For now, I've disabled LPTICKER on all MIMXRT106x targets, which prevents the crash.

Failures after the first failing test in a greentea test suite are ignored

I noticed that there was a Greentea suite where multiple tests failed, but only assertions from the first failing test printed failures. No assert failures were printed from subsequent tests (!).

This appears to be due to the fact that Unity uses a variable (Unity.CurrentTestFailed) to track if a failure has occurred and, if so, skips subsequent assertions. This variable is supposed to be reset after each test when UnityConcludeTest() is called, but it appears that Mbed OS does not call this function ever.

mbed-usb-device-serial test failing

In CI, this test gets halfway through, then fails with:

[1663456332.04][CONN][RXD] >>> Running case #3: 'CDC RX single bytes concurrent'...
[1663456332.09][CONN][INF] found KV pair in stream: {{__testcase_start;CDC RX single bytes concurrent}}, queued...
[1663456332.17][CONN][INF] found KV pair in stream: {{send_single;0}}, queued...
Exception in thread Thread-4:
Traceback (most recent call last):
  File "/usr/lib/python3.9/threading.py", line 954, in _bootstrap_inner
    self.run()
  File "/usr/lib/python3.9/threading.py", line 892, in run
    self._target(*self._args, **self._kwargs)
  File "/home/jenkins/workspace/mbed-os-ce/drivers/usb/tests/TESTS/host_tests/usb_device_serial.py", line 215, in send_data_sequence
    mbed_serial.reset_input_buffer()
  File "/home/jenkins/.local/lib/python3.9/site-packages/serial/serialposix.py", line 683, in reset_input_buffer
    self._reset_input_buffer()
  File "/home/jenkins/.local/lib/python3.9/site-packages/serial/serialposix.py", line 677, in _reset_input_buffer
    termios.tcflush(self.fd, termios.TCIFLUSH)
termios.error: (5, 'Input/output error')

I have also seen:

[1663454516.95][CONN][RXD] >>> Running case #3: 'CDC RX single bytes concurrent'...
[1663454517.01][CONN][INF] found KV pair in stream: {{__testcase_start;CDC RX single bytes concurrent}}, queued...
[1663454517.09][CONN][INF] found KV pair in stream: {{send_single;0}}, queued...
[1663454517.64][CONN][RXD] <greentea test suite>:423::FAIL: Expected 255 Was 94
[1663454517.69][HTST][INF] TEST ERROR: Write timeout
[1663454517.69][HTST][INF] __notify_complete(False)
[1663454517.69][HTST][INF] __exit_event_queue received
[1663454517.69][HTST][INF] test suite run finished after 5.80 sec...

This happens with both the LPC1768 and STM32F4 targets so I assume it's a target-agnostic issue, but can't really say for sure.

wrong define for LED1 and Button in BLACKPILL_F411CE

The defines in PinNames.h for the new target contain '=' and ',' and using this symbols gives compiler errors. The defines should look like this:

    // Generic signals namings
#define LED1        PC_13
    // Standardized button names
#define BUTTON1     USER_BUTTON

@JohnK1987

Figure out how to stop linker scripts from showing up as CMake targets

Currently, in CLion, the build menu is clogged up by having a linker script target for every processor supported by Mbed, This also affects the make help output from the build system. It would be great if we could find a way to hide these, or at least hide them for targets that are not the current target. I did look into this briefly at one point but it's not a very simple task.

Fix Python requirements.txt

The requirements.txt is tied to a specific Python version and causes a lot of issues when you try to use a different version. It should be changed to remove most/all of the maximum version specifiers.

Upload methods should have a way to specify whether the debugger halts/resets on connect

Currently, the different suupported GDB servers do different things on connection:

Some reset the chip, while others don't
Some halt the chip, while others don't

To the extent possible, we should standardize this behavior and allow users to select what they want. Maybe make a number of different gdbserver targets such as gdb-halt-reset, gdb-reset, gdb-halt, and gdb-continue? It could also be a CMake variable but I think having the targets available might make things more convenient.

Increase default baudrate to 115200

Come on now, 9600 baud is what our parents used...

I think this will also have to get changed in the test suite and in the mbedhtrun settings/arguments.

GigaDevice serial_api.c not respecting STDIO baud rate

See Mbed OS issue ARMmbed#15084

I2C is easy to misuse

The Mbed I2C implementation has two restrictions that are easy to violate:

Only one I2C object may be created for each I2C peripheral on the chip
The frequency must be set at the bus level, not at the per-device level, because I2C has to run at the lowest-common-demoninator speed of the slowest device on the bus.

Unfortunately, these are not made clear in the docs, and even some of the built-in drivers (I2CEEBlockDevice) violate them e.g. by having a constructor that takes pins instead of an I2C object. To make matters worse, violating the restrictions will appear to work fine in some scenarios, only to cause undefined behavior later on.

To fix this, we should:

Implement asserts (or at least warnings) that detect when multiple I2C instances are created on the same hardware, and when the frequency of a bus is set multiple times.
Refactor all first-party code to only take an I2C instance, not pins, and not set the frequency after construction
Add information to the docs about this.

Reenable all remaining Mbed unit tests

There are still some Mbed unit tests that are only set up for the old (legacy) test system, which we don't use because it builds Mbed again for every test (!).

The following directories still need to be converted:

connectivity/FEATURE_BLE/source/cordio/TESTS
connectivity/lorawan/tests/TESTS/
~~connectivity/mbedtls/tests/TESTS/~~ (#189)
~~connectivity/netsocket/tests/TESTS/netsocket~~ (#189)
connectivity/netsocket/tests/TESTS/network
~~storage/blockdevice/tests/TESTS~~ (#270)
storage/filesystem/tests/TESTS
storage/kvstore/tests/TESTS

STM32 I2C API v1 fails some I2C tests

The test case currently outputs:

4: [1667837160.17][CONN][RXD] >>> Running case #1: 'Correct Address - Single Byte'...
4: [1667837160.17][CONN][INF] found KV pair in stream: {{__testcase_start;Correct Address - Single Byte}}, queued...
4: [1667837160.17][CONN][INF] found KV pair in stream: {{__testcase_finish;Correct Address - Single Byte;1;0}}, queued...
4: [1667837160.18][CONN][RXD] >>> 'Correct Address - Single Byte': 1 passed, 0 failed
4: [1667837160.18][CONN][RXD] <greentea test suite>:0::PASS
4: [1667837160.18][CONN][RXD]
4: [1667837160.18][CONN][RXD] >>> Running case #2: 'Correct Address - Transaction'...
4: [1667837160.18][CONN][INF] found KV pair in stream: {{__testcase_start;Correct Address - Transaction}}, queued...
4: [1667837160.20][CONN][RXD] >>> 'Correct Address - Transaction': 1 passed, 0 failed
4: [1667837160.20][CONN][RXD] <greentea test suite>:0::PASS
4: [1667837160.20][CONN][RXD]
4: [1667837160.20][CONN][INF] found KV pair in stream: {{__testcase_finish;Correct Address - Transaction;1;0}}, queued...
4: [1667837160.22][CONN][RXD] >>> Running case #3: 'Incorrect Address - Single Byte'...
4: [1667837160.22][CONN][RXD] <greentea test suite>:55::FAIL: Expected 1 Was 2
4: [1667837160.22][CONN][INF] found KV pair in stream: {{__testcase_start;Incorrect Address - Single Byte}}, queued...
4: [1667837160.22][CONN][INF] found KV pair in stream: {{__testcase_finish;Incorrect Address - Single Byte;0;1}}, queued...
4: [1667837160.23][CONN][RXD] >>> 'Incorrect Address - Single Byte': 0 passed, 1 failed with reason 'Test Cases Failed'
4: [1667837160.23][CONN][RXD]
4: [1667837160.23][CONN][RXD]
4: [1667837160.23][CONN][RXD] >>> Running case #4: 'Incorrect Address - Transaction'...
4: [1667837160.25][CONN][RXD] >>> 'Incorrect Address - Transaction': 1 passed, 0 failed
4: [1667837160.25][CONN][INF] found KV pair in stream: {{__testcase_start;Incorrect Address - Transaction}}, queued...
4: [1667837160.25][CONN][INF] found KV pair in stream: {{__testcase_finish;Incorrect Address - Transaction;1;0}}, queued...
4: [1667837160.26][CONN][RXD] <greentea test suite>:0::PASS
4: [1667837160.26][CONN][RXD]
4: [1667837160.26][CONN][RXD] >>> Running case #5: 'Incorrect Address - Async'...
4: [1667837160.26][CONN][INF] found KV pair in stream: {{__testcase_start;Incorrect Address - Async}}, queued...
4: [1667837160.26][CONN][INF] found KV pair in stream: {{__testcase_finish;Incorrect Address - Async;1;0}}, queued...
4: [1667837160.28][CONN][RXD] >>> 'Incorrect Address - Async': 1 passed, 0 failed
4: [1667837160.28][CONN][RXD] <greentea test suite>:0::PASS
4: [1667837160.28][CONN][RXD]
4: [1667837160.28][CONN][RXD] >>> Running case #6: 'Simple Write - Single Byte'...
4: [1667837160.28][CONN][INF] found KV pair in stream: {{__testcase_start;Simple Write - Single Byte}}, queued...
4: [1667837160.30][CONN][RXD] >>> 'Simple Write - Single Byte': 1 passed, 0 failed
4: [1667837160.30][CONN][RXD] <greentea test suite>:0::PASS
4: [1667837160.30][CONN][RXD]
4: [1667837160.30][CONN][RXD] >>> Running case #7: 'Simple Read - Single Byte'...
4: [1667837160.30][CONN][INF] found KV pair in stream: {{__testcase_finish;Simple Write - Single Byte;1;0}}, queued...
4: [1667837160.31][CONN][RXD] >>> 'Simple Read - Single Byte': 1 passed, 0 failed
4: [1667837160.31][CONN][RXD] <greentea test suite>:0::PASS
4: [1667837160.31][CONN][RXD]
4: [1667837160.31][CONN][INF] found KV pair in stream: {{__testcase_start;Simple Read - Single Byte}}, queued...
4: [1667837160.31][CONN][INF] found KV pair in stream: {{__testcase_finish;Simple Read - Single Byte;1;0}}, queued...
4: [1667837160.33][CONN][RXD] >>> Running case #8: 'Simple Write - Transaction'...
4: [1667837160.33][CONN][INF] found KV pair in stream: {{__testcase_start;Simple Write - Transaction}}, queued...
4: [1667837160.33][CONN][INF] found KV pair in stream: {{__testcase_finish;Simple Write - Transaction;1;0}}, queued...
4: [1667837160.34][CONN][RXD] >>> 'Simple Write - Transaction': 1 passed, 0 failed
4: [1667837160.34][CONN][RXD] <greentea test suite>:0::PASS
4: [1667837160.34][CONN][RXD]
4: [1667837160.34][CONN][RXD] >>> Running case #9: 'Simple Read - Transaction'...
4: [1667837160.34][CONN][INF] found KV pair in stream: {{__testcase_start;Simple Read - Transaction}}, queued...
4: [1667837160.36][CONN][RXD] >>> 'Simple Read - Transaction': 1 passed, 0 failed
4: [1667837160.36][CONN][RXD] <greentea test suite>:0::PASS
4: [1667837160.36][CONN][RXD]
4: [1667837160.36][CONN][RXD] >>> Running case #10: 'Mixed Usage - Single Byte -> repeated -> Transaction'...
4: [1667837160.36][CONN][INF] found KV pair in stream: {{__testcase_finish;Simple Read - Transaction;1;0}}, queued...
4: [1667837160.38][CONN][RXD] <greentea test suite>:141::FAIL: Expected 0 Was 1
4: [1667837160.38][CONN][INF] found KV pair in stream: {{__testcase_start;Mixed Usage - Single Byte -> repeated -> Transaction}}, queued...
4: [1667837160.39][CONN][RXD] >>> 'Mixed Usage - Single Byte -> repeated -> Transaction': 0 passed, 1 failed with reason 'Test Cases Failed'
4: [1667837160.39][CONN][RXD]
4: [1667837160.39][CONN][RXD]
4: [1667837160.39][CONN][INF] found KV pair in stream: {{__testcase_finish;Mixed Usage - Single Byte -> repeated -> Transaction;0;1}}, queued...
4: [1667837160.41][CONN][RXD] >>> Running case #11: 'Mixed Usage - Transaction -> repeated -> Single Byte'...
4: [1667837160.41][CONN][INF] found KV pair in stream: {{__testcase_start;Mixed Usage - Transaction -> repeated -> Single Byte}}, queued...
4: [1667837160.42][CONN][RXD] <greentea test suite>:150::FAIL: Expected 0 Was 1
4: [1667837160.42][CONN][INF] found KV pair in stream: {{__testcase_finish;Mixed Usage - Transaction -> repeated -> Single Byte;0;1}}, queued...
4: [1667837160.44][CONN][RXD] >>> 'Mixed Usage - Transaction -> repeated -> Single Byte': 0 passed, 1 failed with reason 'Test Cases Failed'
4: [1667837160.44][CONN][RXD]
4: [1667837160.44][CONN][RXD]
4: [1667837160.44][CONN][RXD] >>> Running case #12: 'Simple Write - Async'...
4: [1667837160.44][CONN][INF] found KV pair in stream: {{__testcase_start;Simple Write - Async}}, queued...
4: [1667837160.46][CONN][RXD] >>> 'Simple Write - Async': 1 passed, 0 failed
4: [1667837160.46][CONN][RXD] <greentea test suite>:0::PASS
4: [1667837160.46][CONN][RXD]
4: [1667837160.46][CONN][RXD] >>> Running case #13: 'Simple Read - Async'...
4: [1667837160.46][CONN][INF] found KV pair in stream: {{__testcase_finish;Simple Write - Async;1;0}}, queued...
4: [1667837160.46][CONN][INF] found KV pair in stream: {{__testcase_start;Simple Read - Async}}, queued...
4: [1667837160.47][CONN][RXD] >>> 'Simple Read - Async': 1 passed, 0 failed
4: [1667837160.47][CONN][RXD] <greentea test suite>:0::PASS
4: [1667837160.47][CONN][RXD]
4: [1667837160.47][CONN][INF] found KV pair in stream: {{__testcase_finish;Simple Read - Async;1;0}}, queued...
4: [1667837160.49][CONN][RXD] >>> Running case #14: 'Mixed Usage - Async -> repeated -> Transaction'...
4: [1667837160.49][CONN][INF] found KV pair in stream: {{__testcase_start;Mixed Usage - Async -> repeated -> Transaction}}, queued...
4: [1667837160.49][CONN][INF] found KV pair in stream: {{__testcase_finish;Mixed Usage - Async -> repeated -> Transaction;1;0}}, queued...
4: [1667837160.50][CONN][RXD] >>> 'Mixed Usage - Async -> repeated -> Transaction': 1 passed, 0 failed
4: [1667837160.50][CONN][RXD] <greentea test suite>:0::PASS
4: [1667837160.50][CONN][RXD]
4: [1667837160.50][CONN][RXD] >>> Running case #15: 'Mixed Usage - Async -> repeated -> Single Byte'...
4: [1667837160.52][CONN][RXD] >>> 'Mixed Usage - Async -> repeated -> Single Byte': 1 passed, 0 failed
4: [1667837160.52][CONN][INF] found KV pair in stream: {{__testcase_start;Mixed Usage - Async -> repeated -> Single Byte}}, queued...
4: [1667837160.52][CONN][INF] found KV pair in stream: {{__testcase_finish;Mixed Usage - Async -> repeated -> Single Byte;1;0}}, queued...
4: [1667837160.54][CONN][RXD] <greentea test suite>:0::PASS
4: [1667837160.54][CONN][RXD]
4: [1667837160.54][CONN][RXD] >>> Running case #16: 'Mixed Usage - Transaction -> repeated -> Async'...
4: [1667837160.54][CONN][INF] found KV pair in stream: {{__testcase_start;Mixed Usage - Transaction -> repeated -> Async}}, queued...
4: [1667837160.63][CONN][RXD] <greentea test suite>:226::FAIL: Expected 0 Was 1
4: [1667837160.63][CONN][INF] found KV pair in stream: {{__testcase_finish;Mixed Usage - Transaction -> repeated -> Async;0;1}}, queued...
4: [1667837160.65][CONN][RXD] >>> 'Mixed Usage - Transaction -> repeated -> Async': 0 passed, 1 failed with reason 'Test Cases Failed'
4: [1667837160.65][CONN][RXD]
4: [1667837160.65][CONN][RXD]
4: [1667837160.65][CONN][RXD] >>> Running case #17: 'Mixed Usage - Single Byte -> repeated -> Async'...
4: [1667837160.65][CONN][INF] found KV pair in stream: {{__testcase_start;Mixed Usage - Single Byte -> repeated -> Async}}, queued...
4: [1667837161.66][CONN][RXD] <greentea test suite>:248::FAIL: Expected 0 Was 2
4: [1667837161.67][CONN][RXD] >>> 'Mixed Usage - Single Byte -> repeated -> Async': 0 passed, 1 failed with reason 'Test Cases Failed'
4: [1667837161.67][CONN][RXD]
4: [1667837161.67][CONN][RXD]
4: [1667837161.67][CONN][INF] found KV pair in stream: {{__testcase_finish;Mixed Usage - Single Byte -> repeated -> Async;0;1}}, queued...
4: [1667837161.69][CONN][RXD] >>> Running case #18: 'Async causes thread to sleep?'...
4: [1667837161.69][CONN][INF] found KV pair in stream: {{__testcase_start;Async causes thread to sleep?}}, queued...
4: [1667837162.69][CONN][RXD] <greentea test suite>:269::FAIL: Expected 0 Was 2
4: [1667837162.69][CONN][INF] found KV pair in stream: {{__testcase_finish;Async causes thread to sleep?;0;1}}, queued...
4: [1667837162.71][CONN][RXD] >>> 'Async causes thread to sleep?': 0 passed, 1 failed with reason 'Test Cases Failed'
4: [1667837162.71][CONN][RXD]
4: [1667837162.71][CONN][RXD]
4: [1667837162.71][CONN][RXD] >>> Test cases: 12 passed, 6 failed with reason 'Test Cases Failed'
4: [1667837162.71][CONN][RXD] >>> TESTS FAILED!
4: [1667837162.71][CONN][RXD]
4: [1667837162.73][CONN][RXD] -----------------------
4: [1667837162.73][CONN][RXD] 0 Tests 6 Failures 0 Ignored
4: [1667837162.73][CONN][RXD] FAIL
4: [1667837162.73][CONN][INF] found KV pair in stream: {{__testcase_summary;12;6}}, queued...
4: [1667837162.73][CONN][INF] found KV pair in stream: {{end;failure}}, queued...
4: [1667837162.73][CONN][INF] found KV pair in stream: {{__exit;0}}, queued...
4: [1667837162.73][HTST][INF] __exit(0)
4: [1667837162.73][HTST][INF] __notify_complete(False)
4: [1667837162.73][HTST][INF] __exit_event_queue received
4: [1667837162.73][HTST][INF] test suite run finished after 2.65 sec...
4: [1667837162.74][CONN][INF] received special event '__host_test_finished' value='True', finishing
4: [1667837162.79][HTST][INF] CONN exited with code: 0
4: [1667837162.79][HTST][INF] Some events in queue
4: [1667837162.79][HTST][INF] stopped consuming events
4: [1667837162.79][HTST][INF] host test result() call skipped, received: False
4: [1667837162.79][HTST][INF] calling blocking teardown()
4: [1667837162.79][HTST][INF] teardown() finished
4: [1667837162.79][HTST][INF] {{result;failure}}
4: CMake Error at mbed-run-greentea-testshield-i2c-basic.cmake:20 (execute_process):
4:   execute_process failed command indexes: 1
4:
4:
1/1 Test #4: testshield-i2c-basic .............***Failed   13.03 sec

Looks like there are two issues in play:

Can't handle repeated starts after single-byte operations
Wrong return code from NACKs in single-byte mode

First time Local Greentea

@multiplemonomials I probably missing something, I followed https://github.com/mbed-ce/mbed-os/wiki/Running-the-Mbed-Greentea-Tests-Locally, but all test failed because the test program can not connect to serial port for some reason. I am sure I have set correct port. I closed all app and for sure also restart my PC. Nothing change. Any hint?

GreenTea console output

C:\Users\User\MbedCE_GreenTea\mbed-os\build_Nucleo_F767ZI>ctest . --output-on-failure
Test project C:/Users/User/MbedCE_GreenTea/mbed-os/build_Nucleo_F767ZI
      Start  1: mbed-drivers-ticker
 1/68 Test  #1: mbed-drivers-ticker ............................***Failed   66.23 sec
[1/1] Flashing mbed-drivers-ticker with STM32CubeProg...
      -------------------------------------------------------------------
                       STM32CubeProgrammer v2.11.0
      -------------------------------------------------------------------

ST-LINK SN  : 0671FF504955657867121730
ST-LINK FW  : V2J40M27
Board       : NUCLEO-F767ZI
Voltage     : 3.24V
SWD freq    : 4000 KHz
Connect mode: Under Reset
Reset mode  : Hardware reset
Device ID   : 0x451
Revision ID : Rev Z
Device name : STM32F76x/STM32F77x
Flash size  : 2 MBytes
Device type : MCU
Device CPU  : Cortex-M7
BL Version  : --



Memory Programming ...
Opening and parsing file: mbed-drivers-ticker.elf
  File          : mbed-drivers-ticker.elf
  Size          : 51.59 KB
  Address       : 0x08000000


Erasing memory corresponding to segment 0:
Erasing internal memory sectors [0 1]
Download in Progress:
██████████████████████████████████████████████████ 100%

File download complete
Time elapsed during download operation: 00:00:01.105

MCU Reset

Software reset is performed
[1662930764.74][HTST][INF] host test executor ver. 1.8.14
[1662930764.74][HTST][INF] copy image onto target... SKIPPED!
[1662930764.76][HTST][INF] starting host test process...
[1662930765.72][CONN][INF] starting connection process...
[1662930765.72][CONN][INF] notify event queue about extra 60 sec timeout for serial port pooling
[1662930765.72][CONN][INF] initializing serial port listener...
[1662930765.72][HTST][INF] setting timeout to: 60 sec
[1662930765.72][SERI][INF] using specified port '3'
[1662930765.72][SERI][INF] serial(port=3, baudrate=9600, read_timeout=0.01, write_timeout=5)
[1662930765.73][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930765.73][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930766.74][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930766.74][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930767.74][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930767.74][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930768.75][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930768.75][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930769.77][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930769.77][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930770.77][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930770.77][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930771.79][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930771.79][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930772.80][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930772.80][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930773.81][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930773.81][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930774.82][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930774.82][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930775.83][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930775.83][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930776.84][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930776.84][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930777.86][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930777.86][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930778.86][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930778.86][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930779.87][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930779.87][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930780.89][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930780.89][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930781.90][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930781.90][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930782.91][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930782.91][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930783.91][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930783.91][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930784.92][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930784.92][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930785.92][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930785.92][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930786.92][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930786.92][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930787.93][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930787.93][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930788.94][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930788.94][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930789.96][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930789.96][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930790.96][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930790.96][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930791.97][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930791.97][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930792.98][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930792.98][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930793.98][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930793.98][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930794.99][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930795.00][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930796.01][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930796.01][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930797.01][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930797.01][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930798.02][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930798.02][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930799.03][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930799.03][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930800.05][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930800.05][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930801.05][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930801.05][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930802.05][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930802.05][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930803.06][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930803.06][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930804.06][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930804.06][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930805.07][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930805.07][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930806.08][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930806.08][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930807.08][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930807.08][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930808.09][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930808.09][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930809.10][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930809.10][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930810.11][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930810.11][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930811.13][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930811.13][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930812.14][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930812.14][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930813.15][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930813.15][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930814.16][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930814.16][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930815.17][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930815.17][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930816.19][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930816.19][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930817.19][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930817.19][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930818.20][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930818.20][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930819.22][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930819.22][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930820.23][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930820.23][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930821.24][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930821.24][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930822.25][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930822.25][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930823.26][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930823.26][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930824.26][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930824.26][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930825.28][SERI][ERR] could not open port '3': FileNotFoundError(2, 'the system cannot find the specified file.', None, 2)
[1662930825.28][SERI][ERR] Retry after 1 sec until 60 seconds
[1662930826.23][HTST][INF] test suite run finished after 60.50 sec...
[1662930826.29][CONN][ERR] Failed to connect to resource
[1662930826.39][HTST][INF] CONN exited with code: 0
[1662930826.39][HTST][INF] Some events in queue
[1662930826.39][HTST][INF] stopped consuming events
[1662930826.39][HTST][INF] host test result(): None
[1662930826.39][HTST][WRN] missing __exit event from DUT
[1662930826.39][HTST][WRN] missing __exit_event_queue event from host test
[1662930826.39][HTST][ERR] missing __exit_event_queue event from host test and no result from host test, timeout...
[1662930826.39][HTST][INF] calling blocking teardown()
[1662930826.39][HTST][INF] teardown() finished
[1662930826.39][HTST][INF] {{result;timeout}}
CMake Error at mbed-run-greentea-mbed-drivers-ticker.cmake:11 (execute_process):
  execute_process failed command indexes:

    1: "Child return code: 5"

Thank you
BR, Jan

Issue with CAN-BUS Extended ID STM32H7

There is an Issue with CAN-BUS Extended ID on STM32H7 ARMmbed#15252
It seems to be easy to solve, but need to verified. I will take look on this next weekend.

There is also a proof about it is working solution.

STMicro devices do not pass USB endpoint halt test

This causes the usb device basic test to fail in CI. See old (unfixed) Mbed issue here: ARMmbed#13215

CMSIS warnings C++17 does not allow 'register' storage class specifier

I get lots of C++17 warnings for compiling CMSIS files: warning: ISO C++17 does not allow 'register' storage class specifier [-Wregister]

Are the mbed-os/tools/profiles used for compiling? There the C++ standard is still set to c++14.

Using gcc-11.3-rel1.

Should this better be reported in the mbed-os repo for easier mainainance?

Add "capability flag" for 0 length I2C transfers

Even though 0-length I2C transfers (where the MCU just sends an address, waits for an ACK, and then stops) are useful (e.g. for scanning the I2C bus for devices), they are a bit of a corner case in the I2C protocol. Some MCUs simply do not support them:

STM32 v2 I2C peripheral allows transactional transfers with 0 length, but not single-byte transfers
RP2040 does not allow 0-length transfers at all in any shape or form

We need a way for MCUs to have "I2C capabilities" that they can share with the application and the test suite, and there should be capabilities for single-byte 0 length transfers and transactional 0 length transfers.

STM32L4: High minimum SPI frequency

I noticed with testing with a logic analyzer that, on STM32L4 chips, the lowest supported SPI clock frequency is about 325kHz. Frequencies lower than that are silently rounded up (!). I think that there are many use cases for SPI that runs slower than that, e.g. trying to asynchronously output some sort of data or waveform in the background. We should see what can be done to decrease this lower limit, both on the L4 and other STM devices.

I2CEEBlockDevice cannot read more than one page at a time in some circumstances.

This issue manifests in the following situation:

You have an EEPROM device that is larger than 256 bytes, but does not use 16-bit addressing (so the upper three bits of the read address are sent through the I2C address byte)
You try to read across a page boundary (e.g. read addresses 0-511, or address 255-256)

In order to do this type of read, the current I2C transaction needs to be ended, and a new one needs to be started for the desired page. Strangely, the program() method has logic to do this, but the read() method does not. This means that doing a read that crosses page boundaries will just end up looping back to the start of the first page instead of returning correct data.

Remove old CI Test Shield files

I don't think we're going to be able to get access to the CI test shield anytime soon. Should remove all the tests/code that use it (hal/tests/TESTS/*fpga* and features/frameworks/COMPONENT_FPGA_CI_TEST_SHIELD)

LPC1768: mbed_interface_disconnect() call makes first sleep take ages

I was looking into some sleep related unit test failures on LPC1768, and found something rather concerning. On this target, the hal_sleep() call (which gets called both by ThisThread::sleep_for and by the RTOS idle thread) includes an operation to disconnect the mbed semihosting interface. The semihosting interface is something of an experiment present only on older boards, where the interface chip uses the debugger to communicate with the MCU, providing access to the local filesystem which is on the interface chip. Why did they overcomplicate it this much? Not sure, but we're stuck with it now.

At any rate, the semihosting is apparently not able to run once the MCU sleeps, so the first sleep call has to disconnect it. Annoyingly, this appears to be a very long-running operation: my testing shows it's right around 4ms. So basically, the first time you call sleep or transition to the idle thread, you're stuck with a 4 millisecond delay before the processor can do anything useful. This is not great and could easily mess with some people's programs, just like it messed with the unit tests.

It would be great if we could fix the delay, but if not, we should at least add a warning about it to the docs. Or, maybe we should just remove semihosting and the LocalFileSystem entirely, since it's basically just a quirk of this one target.

Properly support device internal temperature sensors

Currently, Mbed doesn't directly support devices' internal temperature sensors. We should change that.

For many devices, the temperature sensor is implemented as a virtual I/O pin (ADC_TEMP) which can be used with AnalogIn. For these devices, the temperature sensor implementation can be semi-standardized -- we can layer it on top of the existing analog API, and all that's needed is conversion information.

However, other devices, e.g. MIMXRT, have a bespoke temperature sensor implementation which will require a dedicated HAL implementation.

So, this will need:

A new device_has feature, something like INTERNAL_TEMP_SENSOR
A label or macro like INTERNAL_TEMP_SENSOR_USES_ANALOGIN. If set, the temp sensor API will use the analog in API.
A new HAL containing:
- internaltemp_init() [not implemented if INTERNAL_TEMP_SENSOR_USES_ANALOGIN is set]
- internaltemp_read_raw() [not implemented if INTERNAL_TEMP_SENSOR_USES_ANALOGIN is set]
- internaltemp_convert(), converts from counts into celsius

hal-sleep-manager test failing on nRF52

This test is failing due to another interrupt waking up the core while it's supposed to be deep sleeping. Verified this by disabling all interrupts other than RTC1 -- the test now passes.

Additionally, the test has some very poorly set up checks that were masking this issue behind another message -- "core did not enter deep sleep". The test was only checking the ratios of time elapsed on the lp and us tickers, not the actual times, so when both times were very close to zero, the the test would intermittently fail.

Greentea - mbed-hal-sleep-manager test is failing on STM32H7

Greentea - mbed-hal-sleep-manager test is failing on STM32H7 with assertion - lp ticker sleep time incorrect

Greentea result of mbed-hal-sleep-manager test for Nucleo-H743ZI2

     Start 23: mbed-hal-sleep-manager
23/72 Test #23: mbed-hal-sleep-manager .........................***Failed    5.90 sec
[1/1] Flashing mbed-hal-sleep-manager with STM32CubeProg...
      -------------------------------------------------------------------
                       STM32CubeProgrammer v2.11.0
      -------------------------------------------------------------------

ST-LINK SN  : 002000243156501320323443
ST-LINK FW  : V3J10M3
Board       : NUCLEO-H743ZI
Voltage     : 3.30V
SWD freq    : 24000 KHz
Connect mode: Under Reset
Reset mode  : Hardware reset
Device ID   : 0x450
Revision ID : Rev V
Device name : STM32H7xx
Flash size  : 2 MBytes
Device type : MCU
Device CPU  : Cortex-M7
BL Version  : 0x90



Memory Programming ...
Opening and parsing file: mbed-hal-sleep-manager.elf
Warning: File corrupted. Two or more segments defines the same memory zone
  File          : mbed-hal-sleep-manager.elf
  Size          : 53.23 KB
  Address       : 0x08000000


Erasing memory corresponding to segment 0:
Erasing internal memory sector 0
Download in Progress:
██████████████████████████████████████████████████ 100%

File download complete
Time elapsed during download operation: 00:00:01.052

MCU Reset

Software reset is performed
Executing: mbedhtrun --skip-flashing -p COM27 -e C:/Users/Odiin/MbedCE/MbedCE_Testerino/mbed-os/hal/tests/TESTS/mbed_hal/sleep_manager/../../host_tests -m NUCLEO_H743ZI2 --baud-rate=115200
[1676317617.77][HTST][INF] host test executor ver. 1.8.14
[1676317617.77][HTST][INF] copy image onto target... SKIPPED!
[1676317617.77][HTST][INF] starting host test process...
[1676317619.04][CONN][INF] starting connection process...
[1676317619.04][CONN][INF] notify event queue about extra 60 sec timeout for serial port pooling
[1676317619.04][CONN][INF] initializing serial port listener...
[1676317619.04][SERI][INF] using specified port 'COM27'
[1676317619.04][HTST][INF] setting timeout to: 60 sec
[1676317619.04][SERI][INF] serial(port=COM27, baudrate=115200, read_timeout=0.01, write_timeout=5)
[1676317619.04][SERI][INF] reset device using 'default' plugin...
[1676317619.30][SERI][INF] waiting 1.00 sec after reset
[1676317620.32][SERI][INF] wait for it...
[1676317620.32][SERI][TXD] mbedmbedmbedmbedmbedmbedmbedmbedmbedmbed
[1676317620.32][CONN][INF] sending up to 2 __sync packets (specified with --sync=2)
[1676317620.32][CONN][INF] sending preamble 'f9c3654e-218d-458f-97ea-52c4d8850f5a'
[1676317620.32][SERI][TXD] {{__sync;f9c3654e-218d-458f-97ea-52c4d8850f5a}}
[1676317620.33][CONN][RXD] mbedmbedmbedmbedmbedmbedmbedmbed
[1676317620.35][CONN][RXD] >>> Running 4 test cases...
[1676317620.35][CONN][INF] found SYNC in stream: {{__sync;f9c3654e-218d-458f-97ea-52c4d8850f5a}} it is #0 sent, queued...
[1676317620.35][CONN][INF] found KV pair in stream: {{__version;1.3.0}}, queued...
[1676317620.35][HTST][INF] sync KV found, uuid=f9c3654e-218d-458f-97ea-52c4d8850f5a, timestamp=1676317620.347276
[1676317620.35][CONN][INF] found KV pair in stream: {{__timeout;15}}, queued...
[1676317620.35][CONN][INF] found KV pair in stream: {{__host_test_name;default_auto}}, queued...
[1676317620.35][CONN][INF] found KV pair in stream: {{__testcase_count;4}}, queued...
[1676317620.35][CONN][INF] found KV pair in stream: {{__testcase_name;deep sleep lock/unlock}}, queued...
[1676317620.35][HTST][INF] DUT greentea-client version: 1.3.0
[1676317620.35][HTST][INF] setting timeout to: 15 sec
[1676317620.35][HTST][INF] host test class: '<class 'mbed_os_tools.test.host_tests.default_auto.DefaultAuto'>'
[1676317620.35][HTST][INF] host test setup() call...
[1676317620.35][HTST][INF] CALLBACKs updated
[1676317620.35][HTST][INF] host test detected: default_auto
[1676317620.36][CONN][INF] found KV pair in stream: {{__testcase_name;deep sleep locked USHRT_MAX times}}, queued...
[1676317620.36][CONN][INF] found KV pair in stream: {{__testcase_name;sleep_auto calls sleep/deep sleep based on lock}}, queued...
[1676317620.38][CONN][RXD]
[1676317620.38][CONN][RXD] >>> Running case #1: 'deep sleep lock/unlock'...
[1676317620.38][CONN][INF] found KV pair in stream: {{__testcase_name;deep sleep lock/unlock test_check}}, queued...
[1676317620.38][CONN][INF] found KV pair in stream: {{__testcase_start;deep sleep lock/unlock}}, queued...
[1676317620.38][CONN][INF] found KV pair in stream: {{__testcase_finish;deep sleep lock/unlock;1;0}}, queued...
[1676317620.39][CONN][RXD] >>> 'deep sleep lock/unlock': 1 passed, 0 failed
[1676317620.39][CONN][RXD] <greentea test suite>:0::PASS
[1676317620.39][CONN][RXD]
[1676317620.39][CONN][RXD] >>> Running case #2: 'deep sleep locked USHRT_MAX times'...
[1676317620.41][CONN][INF] found KV pair in stream: {{__testcase_start;deep sleep locked USHRT_MAX times}}, queued...
[1676317620.42][CONN][RXD] >>> 'deep sleep locked USHRT_MAX times': 1 passed, 0 failed
[1676317620.42][CONN][RXD] <greentea test suite>:0::PASS
[1676317620.42][CONN][RXD]
[1676317620.42][CONN][INF] found KV pair in stream: {{__testcase_finish;deep sleep locked USHRT_MAX times;1;0}}, queued...
[1676317620.44][CONN][RXD] >>> Running case #3: 'sleep_auto calls sleep/deep sleep based on lock'...
[1676317620.44][CONN][INF] found KV pair in stream: {{__testcase_start;sleep_auto calls sleep/deep sleep based on lock}}, queued...
[1676317620.59][CONN][RXD] <greentea test suite>:183::FAIL: Values Not Within Delta 65 Expected 655 Was 3. lp ticker sleep time incorrect       
[1676317620.61][CONN][RXD] >>> 'sleep_auto calls sleep/deep sleep based on lock': 0 passed, 1 failed with reason 'Assertion Failed'
[1676317620.61][CONN][RXD]
[1676317620.61][CONN][RXD]
[1676317620.61][CONN][INF] found KV pair in stream: {{__testcase_finish;sleep_auto calls sleep/deep sleep based on lock;0;1}}, queued...        
[1676317620.62][CONN][RXD] >>> Test cases: 2 passed, 1 failed with reason 'Assertion Failed'
[1676317620.62][CONN][RXD] >>> TESTS FAILED!
[1676317620.63][CONN][RXD]
[1676317620.63][CONN][RXD] -----------------------
[1676317620.63][CONN][RXD] 0 Tests 1 Failures 0 Ignored
[1676317620.63][CONN][RXD] FAIL
[1676317620.63][CONN][INF] found KV pair in stream: {{__testcase_summary;2;1}}, queued...
[1676317620.63][CONN][INF] found KV pair in stream: {{end;failure}}, queued...
[1676317620.63][CONN][INF] found KV pair in stream: {{__exit;0}}, queued...
[1676317620.63][HTST][INF] __exit(0)
[1676317620.63][HTST][INF] __notify_complete(False)
[1676317620.63][HTST][INF] __exit_event_queue received
[1676317620.63][HTST][INF] test suite run finished after 0.28 sec...
[1676317620.64][CONN][INF] received special event '__host_test_finished' value='True', finishing
[1676317620.78][HTST][INF] CONN exited with code: 0
[1676317620.78][HTST][INF] Some events in queue
[1676317620.78][HTST][INF] stopped consuming events
[1676317620.78][HTST][INF] host test result() call skipped, received: False
[1676317620.78][HTST][INF] calling blocking teardown()
[1676317620.78][HTST][INF] teardown() finished
[1676317620.78][HTST][INF] {{result;failure}}
CMake Error at mbed-run-greentea-mbed-hal-sleep-manager.cmake:20 (execute_process):
  execute_process failed command indexes:

    1: "Child return code: 1"

Greentea result of mbed-hal-sleep-manager test for future target Wio-H725AE

      Start 23: mbed-hal-sleep-manager
23/71 Test #23: mbed-hal-sleep-manager .........................***Failed    6.13 sec
[1/1] Flashing mbed-hal-sleep-manager with STM32CubeProg...
      -------------------------------------------------------------------
                       STM32CubeProgrammer v2.11.0
      -------------------------------------------------------------------

ST-LINK SN  : 0042004D3431511937393330
ST-LINK FW  : V3J10M3
Board       : STLINK-V3MINIE
Voltage     : 3.34V
SWD freq    : 24000 KHz
Connect mode: Under Reset
Reset mode  : Hardware reset
Device ID   : 0x483
Revision ID : Rev Z
Device name : STM32H72x/STM32H73x
Flash size  : 512 KBytes
Device type : MCU
Device CPU  : Cortex-M7
BL Version  : 0x92



Memory Programming ...
Opening and parsing file: mbed-hal-sleep-manager.elf
  File          : mbed-hal-sleep-manager.elf
  Size          : 53.30 KB
  Address       : 0x08000000


Erasing memory corresponding to segment 0:
Erasing internal memory sector 0
Download in Progress:
██████████████████████████████████████████████████ 100%

File download complete
Time elapsed during download operation: 00:00:01.381

MCU Reset

Software reset is performed
Executing: mbedhtrun --skip-flashing -p COM29 -e C:/Users/USER/MbedCE/MbedCE_Testerino/mbed-os/hal/tests/TESTS/mbed_hal/sleep_manager/../../host_tests -m WIO_H725AE --baud-rate=115200
[1676231388.26][HTST][INF] host test executor ver. 1.8.14
[1676231388.26][HTST][INF] copy image onto target... SKIPPED!
[1676231388.27][HTST][INF] starting host test process...
[1676231389.49][CONN][INF] starting connection process...
[1676231389.49][CONN][INF] notify event queue about extra 60 sec timeout for serial port pooling
[1676231389.49][CONN][INF] initializing serial port listener...
[1676231389.49][SERI][INF] using specified port 'COM29'
[1676231389.49][HTST][INF] setting timeout to: 60 sec
[1676231389.49][SERI][INF] serial(port=COM29, baudrate=115200, read_timeout=0.01, write_timeout=5)
[1676231389.49][SERI][INF] reset device using 'default' plugin...
[1676231389.76][SERI][INF] waiting 1.00 sec after reset
[1676231390.77][SERI][INF] wait for it...
[1676231390.77][SERI][TXD] mbedmbedmbedmbedmbedmbedmbedmbedmbedmbed
[1676231390.77][CONN][INF] sending up to 2 __sync packets (specified with --sync=2)
[1676231390.77][CONN][INF] sending preamble '219d1c70-0bc2-415f-94a5-af04b20944c3'
[1676231390.77][SERI][TXD] {{__sync;219d1c70-0bc2-415f-94a5-af04b20944c3}}
[1676231390.78][CONN][RXD] mbedmbedmbedmbedmbedmbedmbedmbed
[1676231390.78][CONN][INF] found SYNC in stream: {{__sync;219d1c70-0bc2-415f-94a5-af04b20944c3}} it is #0 sent, queued...
[1676231390.78][HTST][INF] sync KV found, uuid=219d1c70-0bc2-415f-94a5-af04b20944c3, timestamp=1676231390.783652
[1676231390.80][CONN][RXD] >>> Running 4 test cases...
[1676231390.80][CONN][INF] found KV pair in stream: {{__version;1.3.0}}, queued...
[1676231390.80][CONN][INF] found KV pair in stream: {{__timeout;15}}, queued...
[1676231390.80][CONN][INF] found KV pair in stream: {{__host_test_name;default_auto}}, queued...
[1676231390.80][CONN][INF] found KV pair in stream: {{__testcase_count;4}}, queued...
[1676231390.80][CONN][INF] found KV pair in stream: {{__testcase_name;deep sleep lock/unlock}}, queued...
[1676231390.80][HTST][INF] DUT greentea-client version: 1.3.0
[1676231390.80][HTST][INF] setting timeout to: 15 sec
[1676231390.80][HTST][INF] host test class: '<class 'mbed_os_tools.test.host_tests.default_auto.DefaultAuto'>'
[1676231390.80][HTST][INF] host test setup() call...
[1676231390.80][HTST][INF] CALLBACKs updated
[1676231390.80][HTST][INF] host test detected: default_auto
[1676231390.82][CONN][RXD]
[1676231390.82][CONN][INF] found KV pair in stream: {{__testcase_name;deep sleep locked USHRT_MAX times}}, queued...
[1676231390.82][CONN][INF] found KV pair in stream: {{__testcase_name;sleep_auto calls sleep/deep sleep based on lock}}, queued...
[1676231390.82][CONN][INF] found KV pair in stream: {{__testcase_name;deep sleep lock/unlock test_check}}, queued...
[1676231390.83][CONN][RXD] >>> Running case #1: 'deep sleep lock/unlock'...
[1676231390.83][CONN][RXD] >>> 'deep sleep lock/unlock': 1 passed, 0 failed
[1676231390.83][CONN][INF] found KV pair in stream: {{__testcase_start;deep sleep lock/unlock}}, queued...
[1676231390.83][CONN][INF] found KV pair in stream: {{__testcase_finish;deep sleep lock/unlock;1;0}}, queued...
[1676231390.85][CONN][RXD] <greentea test suite>:0::PASS
[1676231390.85][CONN][RXD]
[1676231390.85][CONN][RXD] >>> Running case #2: 'deep sleep locked USHRT_MAX times'...
[1676231390.85][CONN][INF] found KV pair in stream: {{__testcase_start;deep sleep locked USHRT_MAX times}}, queued...
[1676231390.86][CONN][INF] found KV pair in stream: {{__testcase_finish;deep sleep locked USHRT_MAX times;1;0}}, queued...
[1676231390.88][CONN][RXD] >>> 'deep sleep locked USHRT_MAX times': 1 passed, 0 failed
[1676231390.88][CONN][RXD] <greentea test suite>:0::PASS
[1676231390.88][CONN][RXD]
[1676231390.88][CONN][RXD] >>> Running case #3: 'sleep_auto calls sleep/deep sleep based on lock'...
[1676231390.88][CONN][INF] found KV pair in stream: {{__testcase_start;sleep_auto calls sleep/deep sleep based on lock}}, queued...
[1676231391.05][CONN][RXD] <greentea test suite>:183::FAIL: Values Not Within Delta 65 Expected 655 Was 3. lp ticker sleep time incorrect
[1676231391.05][CONN][INF] found KV pair in stream: {{__testcase_finish;sleep_auto calls sleep/deep sleep based on lock;0;1}}, queued...
[1676231391.07][CONN][RXD] >>> 'sleep_auto calls sleep/deep sleep based on lock': 0 passed, 1 failed with reason 'Assertion Failed'
[1676231391.07][CONN][RXD]
[1676231391.07][CONN][RXD]
[1676231391.07][CONN][RXD] >>> Test cases: 2 passed, 1 failed with reason 'Assertion Failed'
[1676231391.07][CONN][RXD] >>> TESTS FAILED!
[1676231391.07][CONN][RXD]
[1676231391.07][CONN][RXD] -----------------------
[1676231391.07][CONN][RXD] 0 Tests 1 Failures 0 Ignored
[1676231391.07][CONN][RXD] FAIL
[1676231391.08][CONN][INF] found KV pair in stream: {{__testcase_summary;2;1}}, queued...
[1676231391.08][CONN][INF] found KV pair in stream: {{end;failure}}, queued...
[1676231391.08][CONN][INF] found KV pair in stream: {{__exit;0}}, queued...
[1676231391.08][HTST][INF] __exit(0)
[1676231391.08][HTST][INF] __notify_complete(False)
[1676231391.08][HTST][INF] __exit_event_queue received
[1676231391.08][HTST][INF] test suite run finished after 0.28 sec...
[1676231391.10][CONN][INF] received special event '__host_test_finished' value='True', finishing
[1676231391.21][HTST][INF] CONN exited with code: 0
[1676231391.21][HTST][INF] Some events in queue
[1676231391.21][HTST][INF] stopped consuming events
[1676231391.21][HTST][INF] host test result() call skipped, received: False
[1676231391.21][HTST][INF] calling blocking teardown()
[1676231391.21][HTST][INF] teardown() finished
[1676231391.21][HTST][INF] {{result;failure}}
CMake Error at mbed-run-greentea-mbed-hal-sleep-manager.cmake:20 (execute_process):
  execute_process failed command indexes:

    1: "Child return code: 1"

BR, Jan

Cannot get CMake graph for custom target

Hi @multiplemonomials,

Note Editing the original issue as I didn't know it was already fixed 😅

First of all thank you for creating this project. A lot of work that I do depends on mbed-os and their sudden disappearance got a lot of us anxious. Hopefully, this project keeps it alive and even makes it better than the original! 🏆

I want to get the graph of dependency that cmake generates using the following command:

cmake -B build -S . && cmake --graphviz=dot/dot build && dot dot/dot -Tpdf -o dot/dot.pdf

But I get the following error for my custom target...

-- mbedos found: /home/triutkarsh/.local/opt/mbed-os-src
'mbed-tools' 'configure' '-t' 'GCC_ARM' '-m' 'CUSTOM_TARGET' '-o' '/home/triutkarsh/firmware/build' '-b'
 'develop' '--mbed-os-path' '/home/triutkarsh/.local/opt/mbed-os-src'
mbed_config.cmake has been generated and written to '/home/triutkarsh/firmware/build/mbed_config.cmake'
-- Found Python3: /usr/bin/python3.8 (found version "3.8.10") found components: Interpreter 
-- Checking for Python package intelhex -- found
-- Checking for Python package prettytable -- found
-- Checking for Python package future -- found
-- Checking for Python package jinja2 -- found
-- Checking for Python package mbed_tools -- found
CMake Error at /home/triutkarsh/.local/opt/mbed-os-src/tools/cmake/mbed_generate_configuration.cmake:21 (messa
ge):
  You must define MBED_TARGET to the Mbed target you wish to build for!
Call Stack (most recent call first):
  /home/triutkarsh/.local/opt/mbed-os-src/tools/cmake/app.cmake:42 (include)
  CMakeLists.txt:33 (include)


-- Configuring incomplete, errors occurred!

Thanks and cheers. 🍻

Convert remaining optional libraries to OBJECT instead of INTERFACE

Mbed has a bunch of optional libraries (e.g. for cryptography, networking, device drivers, etc). Currently these are all INTERFACE targets, so they get compiled again for each target they link to. These need to be converted to OBJECT libraries. The steps (for an imaginary library mbed-foo) are as follows:

Convert add_library(mbed-foo INTERFACE) to add_library(mbed-foo OBJECT EXCLUDE_FROM_ALL)
Convert target_include_directories(mbed-foo INTERFACE ... to target_include_directories(mbed-foo PUBLIC .... Same for target_compile_options() and target_compile_definitions()
Convert target_sources(mbed-foo INTERFACE ... to target_sources(mbed-foo PRIVATE ...

Then build and fix any errors that show up.

USB MSD tests do not pass on STM32F7/F4 devices

See old (unfixed) Mbed issue here: ARMmbed#15129

mbed-hal-rtc-reset test kills MIMXRT1050_EVK

After running the mbed-hal-rtc-reset test, something really bad happens to the DAPLink debugger and/or the Redlink debug tool on this target. The board is unable to be programmed anymore, and is totally inoperable until it's disconnected and reconnected.

The test appears to run normally and passes, but then any subsequent attempt to program the target gets

Ns: MCUXpresso IDE RedlinkMulti Driver v11.6 (Oct  3 2022 08:09:13 - crt_emu_cm_redlink.exe build 9)
Pc: (  0) Reading remote configuration
Wc(03). No cache support.
Nc: Found chip XML file in I:/RPL/mbed-os/targets/upload_method_cfg/redlink_cfgs\MIMXRT1052xxxxB.xml
Pc: (  5) Remote configuration complete
Nc: Restarted LinkServer process (PID 30668).
Wc: ============= SCRIPT: RT1050_connect.scp =============
Wc: RT1050 Connect Script
Wc: DpID = 0BD11477
Wc: APID = 0x04770041
Wc: Disabling MPU
Wc: Configure FlexRAM for 256KB OC RAM, 128KB I-TCM, 128KB D-TCM
Wc: Finished
Wc: ============= END SCRIPT =============================
Nc: Probe Firmware: DAPLink CMSIS-DAP (ARM)
Nc: Serial Number:  0227000047784e4500559004d7450044ddb1000097969900
Nc: VID:PID:  0D28:0204
Nc: USB Path: \\?\hid#vid_0d28&pid_0204&mi_03#7&316d2a6&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
Nc: Using memory from core 0 after searching for a good core
Pc: ( 30) Emulator Connected
Xr:
Pc: ( 40) Debug Halt
Nc: connection failed - Ep(03). Invalid ID for processor... Retrying
Nc: Using memory from core 0 after searching for a good core
Nc: On debug connection - reset using system reset
Pc: ( 30) Emulator Connected
Pc: ( 40) Debug Halt
Ed:02: Failed on connect: Ep(03). Invalid ID for processor.
Et: Probe(0): Connected&Reset. Was: NotConnected. DpID: 0BD11477. CpuID: 00000FFF. Info: <None>
Nc:   Last stub error 0: OK
Nc:   Last sticky error: 0x0 AIndex: 0
Nc:   Debug bus selected: MemAp 0
Nc:   DAP Speed test unexecuted or failed
Nc: Debug protocol: SWD. RTCK: Disabled. Vector catch: Disabled.
Pc: (100) Target Connection Failed

STM32 I2C HAL does not handle NACKs properly in single-byte mode

STMicro made some... interesting choices in their implementation of the single-byte I2C API. These choices cause it to not comply with the expected behavior for the API.

How their code works, in general, is:

User calls i2c_byte_write() with byte N
Byte N is clocked in to the I2C output register (TXDR). The hardware can then begin outputting it.
Return 1 from i2c_byte_write() (no real way to detect an error for byte N, because we didn't wait for it to be written out)
User calls i2c_byte_write() with byte N+1
We wait for the TCR flag, indicating that the previous byte has been written out
- If the previous byte was NACKed, we never get this flag, so we go to the timeout case and return 2
- Also: potential race condition here, since we don't wait one full byte time like we need to
Once the TCR flag sets, indicating byte N has been sent, we write out byte N+1 to TXDR

The huge issue here is, if we get a NACK on byte N, this shows up as a timeout error, not a NACK, and it shows up for byte N+1, not byte N. The Mbed devs were apparently aware of this issue, and considered it not serious enough to fix (see ARMmbed#9447). However, this is a very serious issue, because it means that single-byte I2C does not behave in the expected way on STMicro devices.

Consider the following code, where someone tries to write an I2C scanner:

addressToUse = 0;
for(uint8_t address : possibleI2CAddresses)
{
    i2c.start();
    if(i2c.write(address << 1) == 1)
    {
        // device found
        i2c.stop();
        addressToUse = address;
        break;
    }
    i2c.stop();
}

This would work as expected on most devices, but not STM32s! There is no way for the current API to return a NACK on the address byte, so it would look like any address you tried to access was present on the bus. Clearly, this is not OK behavior and needs to be fixed.

Add -fno-threadsafe-statics flag to GCC

Due to experiences I may or may not have had at a place not to be named, I learned that the -fno-threadsafe-statics flag is important for using C++ on embedded devices. Without this flag, defining a static variable in a C++ function causes a bunch of exception handling code to get linked into your program, increasing flash usage by 10s of kilobytes. We should add this flag to the GCC toolchain script.