First of all thanks guys for taking bootloader problem out of our shoulders I work with some ANSI-C low level 8-bit developers were always afraid of this subject. Since 8-bit microcontrollers are becoming more expensive than 32-bit I managed to show my employeer that using .NET Micro Framework would speed up projects using benefits like this one
Could anyone point me in the right direction regarding deployment of devices with application and bootloader on board ? This is how I understand the concept (please correct me if Iâm wrong):
[ol]
I have two managed applications: Main app, Bootloader app
Main app looks up (e.g. on the Internet) for new version of software and when one is detected, application switches to bootloader mode
Bootloader app downloads the new version, validates it, updates the main application and switches back to it application mode
[/ol]
This is of course a case when only managed application is updated, not entire firmware. My questions/doubts:
[ol]
Having a just-shipped-in device how can I upload both application and bootloader?
Can I generate the main application .hex file other way than deploying it to device and downloading it back?
Can I update my bootloader in this process or do I have to make sure no changes will be needed?
[/ol]
You shouldnât need to worry about the bootloader, only your app.
.net runs the CLR, which will in turn, run your application. As far as updates. GHI notifyâs all users of any pending updates⌠then instructs userâs on how and when to update the firmware.
Itâs very transparent leaving you to concentrate on making yourself look brilliant.
You code your application in C# on a free version of VS2010 then deploy to the FEZ by USB.
If your firmware ( I think thats what you mean when you say bootloader ) is out of date watch this video clip and your awayâŚ
[url]- YouTube new version is 4.1.3.0
@ IanR You misunderstood my problem. Iâm thinking about something called IN-FIELD UPDATE. You can read about it more in EMX documentation and under this address:
Imagine this situation. My device is running at customer site. Im not able to connect to device. The device will be connected to Ethernet and can check for updates under predefined Internet address. This is why Im asking about the bootloader and I mean the C# managed version I can create. By firmware I mean what is delivered by GHI. Please having this in mind look once more on my questions.
[quote]1. Having a just-shipped-in device how can I upload both application and bootloader?
[/quote]
You have to Enable boot loader mode then
download the bootloader and firmware. It is up to you how you will switch between the two.
[quote]2. Can I generate the main application .hex file other way than deploying it to device and downloading it back?
[/quote]
It can only be done as described in the documentation.
[quote]3. Can I update my bootloader in this process or do I have to make sure no changes will be needed?
[/quote]
No. The purpose of this is that the bootloader is fixed!
If you need to update the bootloader, you need complete update option.
Thanks Mike. It is clear for me that my bootloader needs to be fixed, just wanted to make sure. Iâm exploring the possibilities of using continuous integration and automatic deployment. Until building solution this is the same as for regular .NET applications. Building hex file however will require hardware presence. I can imagine one EMX board connected to CI server that could be used for deploying the application and downloading the hex file (all using mfdeploy). After that the hex file could be uploaded to a remote location from which devices could download it over the Internet. Any comments on this process ?
Also could someone propose step-by-step how to deploy application with bootloader to a just-shipped-in device so that a process for production could be specified ?
[quote] I can imagine one EMX board connected to CI server that could be used for deploying the application and downloading the hex file (all using mfdeploy). After that the hex file could be uploaded to a remote location from which devices could download it over the Internet. Any comments on this process ?
[/quote]
I am not exaclty sure what you mean, but you must develop your application on an EMX board with changesâŚetc. You have to downlod it and test it⌠When all done, you can read it through MFDeploy and put on your server.
[quote]Also could someone propose step-by-step how to deploy application with bootloader to a just-shipped-in device so that a process for production could be specified ?
[/quote]
Enable Bootloader mode.
Switch to bootloader mode because you are in application mode by default.
Download the bootloader.hex which will update the application.hex and run it.
Programmer is developing a new feature in the application. Each time he commits his changes the build server compiles his code and notifies all team members if a build is broken. The developer/tester can localy upload the application to his EMX board and test the new feature. If feature passes functional tests project manager can hit DEPLOY. Continuous integration server will deploy the compiled application to EMX board, download hex file and send it to remote location for discovery. Thats why the CI server needs one EMX board connected - in order to create the application hex file.
I am not sure.
Do you have an LCD, so you can see output?
Put checks at the start of your program to make sure you are in the correct mode (application vs bootloader)
Yes, Iâm using Cobra board. I determine the current mode by reading the information available on LCD during startup. Sometimes I also use Pizo as checkpoints rather than display.
If I download application .hex file, erase my device and deploy the hex back (all using mfdeploy) the same situation occursâŚ
I suspect you have incompatible versions of TinyBooter and firmware. What version is your TinyBooter and firmware? Look at the LCD, it says Timy Booter mode version xxx when it is in TinyBooter mode. Firmware you can see it on LCD or device capabilities.
If you are not sure whatâs going on, erase your entire board and update TinyBooter and firmware with latest SDK.
Also, try making the âcreate application deploymentâ with a key.
Indeed! I had firmware 4.1.3 and TinyBooter 4.1.1. After upgrading TinyBooter to everything described earlier works like a charm Thank you Mike, I would buy you a beer if it wasnât for the distance
I work with some ANSI-C low level 8-bit developers were always afraid of this subject. Since 8-bit microcontrollers are becoming more expensive than 32-bit I managed to show my employeer that using .NET Micro Framework would speed up projects using benefits like this one 
Graling is buying us beer 
