Hi,
I wanted to develop a bootloader using the RTX kernel operating system and run several tasks for communication and a state machine. I tried out the AN2557 IAP example before and it worked pretty well to jump to a different address. Now my question is:
If I use the RTC kernel for the bootloader, can I still just jump to another address to continue execution of the user program or do I need to do somethin different (i.e kill the tasks of the bootloader)?
Would appreciate any thought on this.
Thanks,
Martin
Why have RTX run your bootloader?
It depends. The bootloader may initialize some MCU peripherals, while the user program may expect them to be uninitialized (fresh out of reset). If that's the case, simply starting the user program may lead to problems. There are several ways to solve the problem: - review the bootloader and the user program code to see if there are conflicting peripheral initializations - if necessary, reset peripherals prior to starting the user program - of reset peripherals prior to initialization in the user program Furthermore, there is a simple bullet-proof method: do a MCU-wide software reset prior to starting the user program. That means setting a 'start user program' flag somewhere prior to the software reset. Early in the boot process (prior to initialization of peripherals) the bootloader would check that the reset was a software reset, and if so it would check the 'start user program' flag, then start the user program or continue executing the bootloader.
to have two independent tasks for the state machine and the communication
Great, thanks! Where do you think would it be best to save the flag state?
It could be any variable with static storage duration in the bootloader. Hopefully, you'll be running the flag-checking code prior to zero-init, so the variable contents will survive a software reset.
But you are most likely able to solve this problem using a super-loop, as mostly no real-time behavior is needed in a bootloader. This will decrease your ROM footprint and program complexity.
I don't think you are following the KISS method here. You are overcomplicating things. There shouldn't be a need for an RTOS in the boot loader to handle a state machine and communication.
On one hand, a single loop can process multiple state machines without any problems. And the majority of the communication would basically make use of hw or sw FIFO or similar
That could be said about many programs. For example, protothreads can handle multiple concurrent processes just fine in a great many applications without sacrificing readability. Usually it is though that a bootloader should be small to leave the bulk of program memory to the main application. However, if memory shortage is not an issue, this point is not valid any more. There is one important reason to keep the bootloader simple. Hopefully, simplicity would lead to fewer bugs. This is important since it is not so easy to replace the bootloader as opposed to the main application.
Why have RTX run your bootloader? .... to have two independent tasks for the state machine and the communication
it is amazing how many of todays grads that would use a RTX for 'blinky' were they to originate it.
Erik