twittich wrote on Thursday, August 15, 2019:
as the title says i want to run two applications at the “same” time. If i make two threads in freertos one for blinking led 1 and one for blinking led 2 it works fine.
But is this also working if blink1 and blink2 are two seperate applications i mean one at location 0x26000 in flash and the other one at 0x50000 ?
Thanks in advance for any help
richard_damon wrote on Thursday, August 15, 2019:
It will need changing your definition of ‘application’ a little if you are thinking in the traditional way embedded applications are built.
Some background. A traditional embedded application is a fully self contained block of code, that a processor reset gets jump into by the boot sequence, it does its initialization, goes into its main function and run. With FreeRTOS, it is still like that as FreeRTOS is a library used WITHIN your application to run multiple tasks with task switching. FreeRTOS is NOT like an operations system like Windows or Linux where the system boots into the OS, and then the OS runs various applications. FreeRTOS is inside your application, not your application inside FreeRTOS.
This means, by the classic method, Two Applications in Flash, each will be built with their own copy of FreeRTOS (and the rest of the system libraries) and each will create their own tasks. As such, neither will create a task for the other application, so nothing in the other application will run.
To do what you seem to be describing would first require making some base ‘Boot’ application which is where FreeRTOS and most of the library lives, and some basic startup code. You could then define various other locations in flash that this boot application looks to and sees if some ‘sub application’ has been loaded, and if so, and it is desired to run it, lets it define what tasks it wants to create and so on. The biggest trick is that these sub-applications need to be build with the understanding that they ARE sub-applications, and rather than pulling in their own version of FreeRTOS and libraries, they use the one built into the boot application.
Generally to do this, you use techniques similar to how you build DLLs or Shared Libraries on bigger OSes, establishing a jump table of entry points, but depending on the ability of the tools, you may need to do a lot of the grunt work yourself to implement this.
twittich wrote on Friday, August 16, 2019:
Thank you for the good explanation.
I’m using the nordic nrf52840 where an example application for blinking in freertos is working. And also jumping to another application is working, but then the freertos one is terminated. Can i use this anyhow to solve my problem without or less base dev of an extra bootloader ?
richard_damon wrote on Friday, August 16, 2019:
You have a fundamental problem. It sounds like you really want you system to have a master OS that different applications can run under. FreeRTOS is not such an OS, but FreeRTOS is a library that runs under a given program that provides multi-tasking ability.
You can jump from one application to another, and that new application can start a new instance of FreeRTOS, but then all that happened under the old instance is gone. This happens because each application assumes that it is starting in a fresh machine and totally re-initializes everything.
To get what you are asking for requires a fundamental change in how the system works. You need to move the OS from being part of the various applications, into something which runs before the application, which make it, at least to the applications, a form of a boot loader so it starts before the appliations. The applications then need to be changed to know that their IS a system outside of themselves that needs to be preserved and used for certain operations, and to not ‘remove’ it as part of the program initialization. This is definitely not a trivial operation.
hs2sf wrote on Friday, August 16, 2019:
You need to stop/disable any interrupt activity (including systick) before launching the other app ( properly). Basically the same as a bootloader would need to do.
I wonder how the FreeRTOS 1 app could terminate after activating the other FreeRTOS app.
In fact there is nothing to terminate and the prev. app code shouldn’t be reached afterwards…
However, this assumes the classic and straight forward to implement method of 2 or more fully fledged, independent FreeRTOS apps (in flash) as Richard explained very well.
twittich wrote on Thursday, August 22, 2019:
Thank you for your reply.
I am adding now the second application as a task., maybe later i have to think about how to proceed with the primary idea:
Maybe it’s to specific on the examples of nordic sdk, but maybe someone has an idea:
The example of freertos has a task for blinking and i added a task for dfu functionality(the dfu bootloader app works fine in standalone) and the dfu device is visible in windows device manager but the other task or timer of blinking gets temrinated and the update is not working…
hs2sf wrote on Thursday, August 22, 2019:
How do you want to update the 2nd application ? This can only be done by a separate bootloader/DFU (application) updating e.g. a different portion of flash with the 2nd application image while running in a separate part of the flash.
Assuming you’re not copying over and running the BL/DFU completely in RAM.
twittich wrote on Friday, August 23, 2019:
First i want to put all in one freertos application as tasks. The idea with the second application i’ll think about later.
Normally the structure is that there is the mbr, a softdevice(library of nordic certifite functions), application, free space, bootloader with dfu functionality. If you call a trigger for dfu mode, the device jumps to the bootloader and starts the dfu mode. now >all< parts of the flash can be updated through usb-serial by there update tool. So it has to be copied in ram otherwise it can’t update the bootloader part.
i have to correct my previous answer, the blink task gets not killed it’s blinking normal so only the update is not working but the led which is controlled by the bootloader part / the other task is also blinking not flashing/softblinking how it should be if it’s ready to initialize the update process.
if i comment out the blink task the led for update stays off…
hs2sf wrote on Friday, August 23, 2019:
So the DFU update itself is not working as expected. Well, this depends on your implementation and the issue can be debugged.
I would carefully verify that the BL (DFU activation) code fully runs in RAM and does not indirectly call any code located in flash. And as already mentioned the previously running FreeRTOS application must be stopped to avoid SysTick/ISRs kicking in (calling code in flash).
Usually this kind of code is very lean because it runs in RAM without any FreeRTOS support.