I see a lot of instructions on how to update but it is steel unclear why we need to do this.
What if I will update only firmware (CLR)?
1 Like
I would also like to know the answer. Worst of all, it is such a complicatd procedure. I remember Gus saying this is going to be necessary only occasionally, but they change it every time a new SDK is released…
1 Like
I also can’t tell you why it is needed to be changed, but I know you can get in big trouble if you don’t.
So just do it and pray that it gets a stable status in the near future.
What kind of troubles?
If I understand correct loader is used for binary deploying and/or for application launching?
Is a loader performs some hardware initialization and may somehow affect to my application work?
@ Sergey Bokhantsev - My guess is that updating firmware, deploying and starting application could go wrong.
Worst case it looks like it’s working, but you get strange behavior somewhere.
I would not risk that. Because when I have something not working, that last thing I would think of is an old boot loader.
The question remains unanswered. What about an official comment from GHI? 
Hmmm, may be the firmware is mainly in the loader :think:
There once was a rumor, then large parts of MS Office are already part of Windows (back to Win3.x or may be 95), and by this MS office was faster then 3rd party word processors
There is a lot of shared code between TinyBooter and TinyCLR. If a change is made in this code TinyBooter needs to be recompiled and deployed along with TinyCLR. Shared variables could change location, the order of initialization could change, how certain peripherals needed in TinyBooter are initialized could change, among many other things. If a change occurs in one but not the other due to using an old TinyBooter, obscure and hard to detect bugs can crop up due to TinyCLR expecting a something to be done in TinyBooter a certain way that is not being done or being done in a different way. It is not trivial to detect when a change in one of the shared code libraries will have that effect so we play it safe and recommend that both are updated.
Unfortunately, TinyBooter shares quite a bit more than the flash driver with TinyCLR, so the chance of a change occurring in code shared by TinyBooter is higher than would be ideal. It just so happens lately that we have made a lot of fixes and improvements to code shared by TinyBooter, thus requiring it to be deployed. We are always looking into ways to reduce the amount that TinyBooter requires and does to lower that chance.
You will probably not find a bug that is the result of a mismatched TinyBooter most times, but they are possible. When they do happen, as Reinhard said, you are likely to not suspect TinyBooter or they will be transient. Even if the issue occurs rarely, it is not always a chance that can be taken for mission critical devices so we strongly recommend always updating TinyBooter when a new version exists.
- If TinyBooter and TinyCLR share so much, then what is the point of having TinyBooter on board?..
- If you change TinyBooter with every release anyway, and you strongly recommend to keep it updated, then what about making the whole process easier? Like, for example, adding a button to Raptor? Or making buttons LDR0 and LDR1 work on G400HDR? Or, better yet, making TinyBooter upgradeable through IFU?
1 Like
@ andre.m - Indeed…
@ Simon from Vilnius - We have actually added a button to the latest revision of the Hydra that brings it into Samba mode. We haven’t done that on the Raptor/G400 because we are hoping to get the same kind of bootloader found on the EMX/G120 on the G400, at which point LDR0 and LDR1 will function as expected.
TinyBooter is mainly meant to ease upgrading the firmware from what I can tell. We are always looking for ways to reduce the amount of shared code so that TinyBooter will only rarely need to be updated.
From a quick glance at the STM version of Tinybooter i am surprised it needs updating everytime…
A bootloader should never share code with main application, its a independent process. If you share information between them its not a loader, its application.
The main application may know things about bootloader but not vise versa.