Contribution to implement vPortEndScheduler for Cortex-Mx ports

hamletg wrote on Friday, December 15, 2017:

To make unit testing and integration testing easier in HW, I had to implement the vPortEndScheduler for the Cortex-Mx ports. So I was wondering if :

  • some others could be interested in those changes
  • if yes, how could I provide the changes? Direct contribution to the FreeRTOS kernel? Or what would be the procedure, because I’m bit confused since the FreeRTOS code is here, in github, on AWS.

BTW, it’s implemented in a way that one can choose to use the modified kernel or the orignal one by a preprocessor define.

rtel wrote on Friday, December 15, 2017:

What executes after the scheduler has ended? Is it implemented in a
portable way so it will work with all the supported compilers?

hamletg wrote on Friday, December 15, 2017:

It merely continues just after prvPortStartFirstTask(), and the call prvTaskExitError() is replaced by a function doing some cleanin up, such that the execution will return ultimetly to the “main” function. Since I followed as strictly as possible the same “portable coding style” as used in the rest of FreeRTOS kernel, so it should work on most supported compilers, but I checked it only with various versions of GCC, since that the only compiler I have readily access too. And this code has been used for about 1 year now on 5 different MCUs so far.

hs2sf wrote on Friday, December 15, 2017:

Sounds very good Michel and thanks for sharing your work !

hamletg wrote on Saturday, December 16, 2017:

Well, I haven’t shared it yet :wink: Merely inquiring if it would be valuable to others and if so how can I make it available.

The whole story behind this comes down to integrating CI with embedded SW, unit tests, and integration tests. I rewrote the boost unit test framework for “deeply embedded system,” I mean by this systems without MMU, so MCUs basically. Of course, this re-write of the boost UTF runs also on PCs, such that I can write unit tests and intergration tests, get them to run on a “virtual HW” on a PC and integrated to CI (Gerrit/Jenkins). But I wanted to run as many of those tests in real HW as well. Since all tests can run on HW without chaning a single line of code, I just needed a way to put as many tests as possible in the MCU flash, to minimize the number of time the flash is written to, since they all have limited write cycles. And this led me to the requirement to be able to get out of scheduler cleanly to be able to terminate the current unit test and give the control back to the unit test framework to start the next unit test.

In this way, we are able to run many tests with only one firmware and thus one flashing. And we integrated the unit test run in HW with our CI as well.

Now you know the whole story behind this :wink:

hs2sf wrote on Saturday, December 16, 2017:

Yes, I assumed this kind of professional background of your extension.
Although I did had the need of the feature yet, it might be useful in the future.
Even if it doesn’t make it into official FreeRTOS release, it’d be nice to put it on e.g. github :slight_smile:

hamletg wrote on Saturday, December 16, 2017:

Actually, I’m planning to put lots of my embedded work as open source projects in the comming weeks, including the re-write of boost UTF and many more. Sure, if my modifications don’t make it in the mainstream FreeRTOS release, I’ll make it available as part of my other projects, since they need those anyway.

rtel wrote on Saturday, December 16, 2017:

Hi Michael,

This sounds great, especially as you have taken the time to describe the
use case where it is really needed.

Historically the FreeRTOS Interactive site has been the place to share
code ( ) but recently the forum host has
prevented people from uploading their code. I need to figure out a new
way of allowing self service uploads, but in the mean time is it
possible you could upload your code somewhere yourself then post a link
to it in the Interactive site? Maybe it is already in a Github rep you
post the URL to?

hamletg wrote on Thursday, December 21, 2017:


Actually, the code is on my private gerrit server, not in github yet. But I’ll setup a github in the comming days and post the link here: I’ll take the opportunity to port the changes to 10.0.0, since I haven’t done that yet.


swichu91 wrote on Sunday, December 24, 2017:

Hi Michael,

I would be also really interested in those changes cause in current job we are implementing clean exit from scheduler using simulation & CI so application use is similar to yours. Right now we’ve implemented it using _exit and semihsoting call but it would be better to use context switching. I assume that your code works that way ?

I would be very greatfull if you post your work on github etc.


billfrank wrote on Tuesday, April 03, 2018:

Awesome to see that someone is working on this. We have been talking about doing it ourselves as we have thought about using it to allow for special operating modes of our devices (ie one set of discrete tasks during normal operation versus a second set for standby/wake and/or fault mode).