Updating Mbed-OS

Hi,

I’ve being trying to bring an old mbed-os project up to date and have run in to a problem with a particular PR. @Kojto expressed an interest so here’s the story…

Back in April 2018 we started a project to develop a LoRaWAN temperature sensor. We selected mbed-os because it included support for our MCU and had a LoRaWAN stack. The alternative seemed to be pulling together several things like LoRa-net, freertos, etc.

I think mbed-os was the correct decision and it has worked quite well for us.

Mbed-os was changing rapidly in 2018. For example, tickless wasn’t initially supported for our target. Hence we used the latest master and kept updating mbed-os. Rather than selecting a release branch.

We considered switching to a release branch but towards the end of 2018 we were getting ready for our first major release and just seemed sensible to stick with the mbed-os we had. I don’t think the precise version is important to the story but if you’re interest our mbed-os.lib looks like https://github.com/ARMmbed/mbed-os/#d20b59153a68571259312d95535bb140f5306deb. This PR is from 10th Jan 2019.

We needed to make mbed-os and , in particular, the LoRaWAN stack, do some non-standard things and to achieve this we apply some patches after doing mbed deploy.

Our device is a STM32L442KC which has 256KB of flash. We use approx 40KB for config and data leaving 0x35800 byes for code. Our production build has 1732 bytes of flash to spare. My perception is that mbed-os uses more memory than strictly necessary. This is partly because it needs to provide abstractions, etc. to be flexible but I don’t think this helps any given project. In other words, we only have one MCU target, and only 1 pin configuration much of the flexibility is wasted on us. The LoRaWAN stack provides for run-time polymorphism, ARM GCC doesn’t optimise out the virtual functions so we have code in our binary that is never executed.

We’re using ARM GCC. I’ve got a feeling that we would get better results with the ARM compiler but purchasing the ARM compiler was never an option for the project. (I appreciate we could get the ARM compiler with MBED-OS Studio but it’s too late now.)

This project was quiet for a while but towards the end of 2019 some issues came to light and we’ve been doing a bit of work on it.

One of the problems is proving unrepeatable and difficult to track down. It could be a race or something equally nasty. We thought it might be good to update to a later version of mbed-os. AFAICT, some good work has been done in mbed-os since Jan 2019.

Unfortunately updating mbed-os is trickier than you might hope.

The main and most obvious problem is that the footprint seems to creep up. A trivial example, Sleep: error flags fix #9277 enables MBED_TRAP_ERRORS_ENABLED and this broke our build. Often a PR will add a few bytes which everyone accepts but a few bytes here and a few bytes there break our build. Occasionally there are improvements but it is my perception that overall the footprint is creeping up.

Clearly having to patch mbed-os is a pain because the patch files sometimes need updating. I don’t think this is the fault of mbed-os but it adds to the rickness of the problem we’re trying to solve!

In an attempt to move our mbed-os version forward I’ve been jumping forward a few PRs and then checking we still build and run. Whenever I bite the bullet and make a big jump something fails, usually running out of memory, and I have to go back. In the case of MBED_TRAP_ERRORS_ENABLED I went back until I realised what the problem was and disabled it again. It is always a concern that I hit a problem that it fixed later on, I know that there are some code savings that I haven’t got to yet, but I’m not sure what else I can do (if we really want to get up to date).

At the moment I’m stuck on Sleep rework, RTOS API for bare metal, wait deprecations #10104. This PR causes the code to increase by 768 bytes and, even after I saved some space elsewhere, the application to behave erratically. (I’ve got a feeling the problem is something to with using tickless driven by the RTC, which is an uncommon configuration.)

I’ve been considering trying to get in sink with the release schedule but I haven’t convinced myself that it will help.

Regards,
Matt