Use mbed-ce as default repo and create a while(1) loop in the default project.

[lefebvresam]

After the default install procedure:
python -m pip install mbed-tools

If you create a new mbed project whith 'mbed-tools configure' there are two major issues:

1/ Not the right mbed repo is checked out. It's still the old one

https://github.com/ARMmbed/mbed-os#master
instead of
https://github.com/mbed-ce/mbed-os.git

2/ The main function does not contain a while(1) loop. In case you use a STLinkV2 clone programmer, there is an issue where the HW Reset pin is not working in the programmer notwithstanding it is available as a pin. When the controller is not hanging in a while(1) loop it goes in sleep and programming during sleep requires programming with HW pin. If you try a lot of times you have a change that SW reset works when the controller just wakes up for a few clock cycles, or you need to buy the original programmer where the HW reset works. If the program has a while(1) loop you can avoid this issue in the first phase of testing.

I refer to an issue about the 'strange' oscillator hiccups: https://forums.mbed.com/t/external-oscillator-hiccups/22198

[JohnK1987]

If you create a new mbed project whith 'mbed-tools configure' there are two major issues:

1/ Not the right mbed repo is checked out. It's still the old one

https://github.com/ARMmbed/mbed-os#master
instead of
https://github.com/mbed-ce/mbed-os.git

MbedCE does not use any old ARM Mbed build system or any ARM Mbed build tool (Mbed CLI and so on). MbedCE has its own new build system - https://github.com/mbed-ce/mbed-os/wiki

So second point I understand the issue with ST-link clone but I do not understand why the default project should have this in default due an error of a ST-link clone. You could add it by your self or?
The price of St-link clone is around 5€. Nice price but I see no point to buy a clone. Original ST-link is on every Nucleo board for free. The price of Nucleo board is from 11€ to 40€ and on newest boards you can found also ST-link V3.

[lefebvresam]

Yes I see price is not an issue but time is. These are typical struggling points where you can lose days and days. I don't know but maybe a section about programming tools and potential issues (or pitfalls) could be on place here. (Or I missed such page) At a first view, the clone looks more elegant, has smaller footprint, smaller connector and is cheap. But on most selling websites there is almost nothing of documentation to find about it. You get it 'just as is' and it's only after measuring with scope, reading sites and losing a lot of time that you realize why you could better not use it except in a specific setup where you know when it will not work and why.

Concerning the CLI it's very confusing to constatate after a few months of testing that the old project is really 'dead' and that you lost a lot of time by trying all tools described (mbed, mbed-tools, etc;) first (and that are mostly still working) before digging into the CE docs. So why the old project is still in the air? ;-)

[JohnK1987]

I personally prefer to buy a Nucleo make some test and then buy same or similar MCU. That should be more save way to final result and ST-link as a benefit. Nwm it happened.
Unfortunately I do not have any clone so I can not make any note about this but we tried what we can - https://github.com/mbed-ce/mbed-os/wiki/STM32-Deploy&Debug

ARM Mbed never gave an official statement about the project is dead. But said the project is slowed down for a time until they make new roadmap. This is for two years now. https://forums.mbed.com/t/will-mbed-os-get-back-its-previous-pace-of-development/15839/4?u=johnnyk
Later Jamie came with this great idea https://forums.mbed.com/t/help-wanted-mbed-ce-a-community-fork-of-mbed-os/17998

How I wrote check MbedCE wiki. I believe you will up very fast.
I remember you like Command line solution - https://github.com/mbed-ce/mbed-os/wiki/Project-Setup:-Command-Line

Feel free to place Issues you found (related to MbedCE and its build system) and we will try what we can.

[lefebvresam]

This is how it goes as a freelancer. I started with a HMI display project with mbed in 2020 during Corona times. But before you know you need to do a paid project and I left the whole development with Nucleo in the cupboard. Now, three years later I want to pickup that project (because of some interests in the industry) and developed my own hardware. But since november I was struggeling with board bringup, compile tools, programming tools and whatever.

I had to add all cmake stuff, create scipts, debug programming tools, doing investigations with Cube, etc. I like to have non commercial and working tools, where nothing is 'hidden' and you are not dependent on any IDE or installing gigabites of software for the first hello world program. The only point is that information is very fragmented and not alway accurate, complete or correct. It would be a pleasure to share my test results until now.

A programming tool that can be added in the list and that I use is ST-Link:

cd ~/git
git clone https://github.com/stlink-org/stlink.git
cd stlink
sudo apt-get update && sudo apt-get install libusb-1.0 libusb-1.0-0-dev
sudo make install
sudo ldconfig

Examples are:

4. Programming in Linux (with clone STLinkV2 - nRST not working)

# Read chip info
st-info --probe

# Full erase
st-flash --freq=4M  erase  0x8000000 0x100000 | sed 's/\r/\n/g'

# Program the bin file and invoke a reset
st-flash --freq=4M --reset write ./cmake_build/HMC20/develop/GCC_ARM/hmc20_test.bin 0x8000000

# Workaround appending issue, reported: https://github.com/stlink-org/stlink/issues/1362
(FILE=./cmake_build/HMC20/develop/GCC_ARM/hmc20_test.bin; python3 append.py $FILE; st-flash --freq=4M --reset write $FILE 0x8000000)

# Read the whole memory (Size 1Mb)
st-flash --freq=4M read flash.bin 0x8000000 0x100000

# Read a piece of memory at a random location
st-flash --freq=4M read mem.bin 0x800BA30 0x20 && hexdump -C mem.bin && rm mem.bin

# Read a page in memory at a page start address (page size 0x2000)
st-flash --freq=4M read page.bin 0x800A000 0x2000

> Open page.bin with hex editor plugin in VSC and edit some data

# Write a page, address of write must start on a multiple of the page size
st-flash --freq=4M write page.bin 0x800A000

If you fit all in a bash script then you create your own CLI:

  echo "$0 [-c|--clean] [-b|--build] [-f|--flash] [-p|--probe] [-e|--erase] [-h|--help] "
  echo "Build the HMC20 application"
  echo "Optional arguments:"
  echo "\tclean   perform make clean first"
  echo "\tbuild   build type release or debug"
  echo "\tflash   flash the chip"
  echo "\tprobe   probe and reset the chip"
  echo "\terase   erase the whole chip"
  echo "\thelp    show this help"

[multiplemonomials]

My 2 cents on this:

• I'd prefer not to make any changes to the code of Mbed CE that are just in service of supporting ST-Link clones. It would be one thing if this was the 00s and this was some proprietary programmer that cost $500+ -- then it would be worth working to support clones. But genuine ST-Links are pretty cheap and ubiquitous (and are on every nucleo board), so I don't feel like they are hard for users to obtain.
• However, I would be onboard with making some edits to the wiki to flag the issues that are common with ST-Link clones -- maybe to the upload methods page, or we could create a new page about recommended programming tools?
• Also keep in mind, it's possible to disable sleep globally by putting

"device_has_remove": ["SLEEP"]

in your custom target definition. That should fix this issue without needing a while(1) loop,

So why the old project is still in the air?

That's a tough question tbh. I've actually talked a bit with Sam Taylor at ARM (one of the last remaining ARM employees with anything to do with Mbed), and he says that Mbed still sees a lot of users in the education sector. Like, there are a lot of college classes and other training courses that rely on the online compiler as a quick & easy way for students to build embedded code. And... it is quick and easy -- I can see why they do that. It's just not very good. And with most of the developers gone from the project, Mbed is starting to fall behind the releases of new chip families and dev boards. I think it's messed up that ARM is willing to keep the project on life support for education users, but isn't willing to actually commit any developer effort to it anymore. It's taking Mbed in the direction of being an educational tool only instead of an OS usable for real stuff.

Sooo, that's one of the reasons I started the Mbed CE project! I want Mbed CE to be the option of choice for people who want something that's actively developed and works a bit better with a professional grade workflow than the official Mbed and its build tools.

A programming tool that can be added in the list and that I use is ST-Link:

You'll be happy to know that Mbed CE already does support the open-source st-link program! Just pass -DUPLOAD_METHOD=STLINK. For some reason I didn't think that st-link supported STM32U5, but I guess it does, so hopefully you can use the existing support to flash your board!

[lefebvresam]

My suggestion is to add a topic about clone programmers (witch schematic etc) which depicts the pitfalls, do's and dont's. I think the low cost could not only be a reason to not talk about it. A lot of (starting) users are doing the first trials with a cheap Aliexpress-like clones and are facing all the same issues. If there is a clear topic about it, it can save them weeks of (paid) days. And this is much more expensive.

Concerning the support MCU_STM32U575xG it works, but with the aliging issue in mind:
See ticket stlink-org/stlink#1362
Which is likely solved by now.

[lefebvresam]

What is "device_has_remove": ["SLEEP"] doing exactly? I did a test and indeed I can program again during sleeps but ThisThread::sleep_for(5000); is not affected.

[multiplemonomials]

Sounds good, feel free to add a topic like that on the wiki!

That's a good question. What that line does is, it removes the DEVICE_SLEEP preprocessor define. That, in turn, affects this function here. mbed_sleep() is called in the RTOS idle thread in a loop, so removing DEVICE_SLEEP turns that function into a no-op and prevents the MCU from going to sleep.

Note that, if you want to see the list of all the defines defined by your current configuration, you can check out the generated file /mbed_config.cmake.