Bootloader practice

Good day again!
Yesterday I wrote about how the current boot-loader operates. Today I would like to write about what I have actually accomplished while working on the new boot-loader.

Draft no.1

First I tried creating a boot-loader that would operate as per the draft no.1 described in the previous post. That is - the program is stored in FLASH in its entirety but right after reset everything gets copied into RAM and is executed from there.
At first I was really fumbling around while trying to accomplish this, but then I found a tutorial (accidentally also written here on Blogger as I have just noticed) which describes basically exactly what I need. The only difference is it is written for a different board than LPC1343, but that's not a huge problem.
By following the instructions from the tutorial I finally managed to succeed. It required a complete rewrite of Crt0.S and ldscripts. There are some little tricks involved in how it all works but I won't describe them here as that would be redundant as they are covered sufficiently in the tutorial.
As I mentioned in the previous post, the program proposed in this draft is not really practical as there is no way the whole firmware will fit in RAM. However, it is useful for testing and presented a nice way to get some more experience before moving onwards to the successive drafts.

A little bit of semantics

Firstly, before I continue writing about the drafts, I think that it would be appropriate to clear up one particular semantic issue that might be confusing to the reader. My ultimate goal is to create a new boot-loader, but a one that will not replace the current boot-loader that is already present. In fact when I am done there will be two sub-programs that one could call a boot-loader - one that is responsible for initialising the micro after reset and which is the currently present one and a second one which is the one I am trying to create and which will allow the micro to be reprogrammed over the RS485 bus. To make things more clear I will refer, from here on, to the first boot-loader as reset-loader and to the second one as IAP-loader.

Drafts 2 & 3

Next up, I started to work on creating an IAP-loader that would work as our draft no.2 specifies. During the actual work I found out that the differences between the no.2 and 3 drafts are, in fact, minimal so I have decided to roll them both up into one project. The only difference between them is that in draft no.2 the actual IAP-loader part cannot be rewritten and can be placed in either FLASH or ROM, when in the no.3 draft the IAP-loader part has the ability to overwrite itself in FLASH and therefore has to be placed in ROM. This can be changed by rewriting about 3 lines of code, hence the justification for merging them both together.
I have also found out that, in the end, the existiong Crt0.S and ldscript files had to be only slightly modified to acheive the desired functionality. Basically it was only necessary to add an extra section that contains all of the IAP-loader code, into the ldscript, link it for RAM, store it in FLASH and extend the copy loop in the reset-loader to copy it all on start-up. Actually it is not even necessary to modify the reset-loader code and we can just do the copying on runtime from the main function.

Problems

So you might ask: If everything was so easy, what took you so long? Well, as usual, I ran into a lot of little problems which slowed me down. One in particular, I fell I have to describe here:
I kept getting usage faults from the processor when it was supposed to execute a jump from the code in FLASH to the IAP-loader code in RAM (basically just calling the IAP-loader function). In the end all that had to be done to solve it was to change the order of the sections contained in the ldscript. When the section containing the IAP-loader code (I labelled it as .boot) is placed before .text I keep getting faults. If it is the other way around, everything works fine. I have no idea why the micro behaves this way; I am just glad it works properly now.

Future concerns

While working on the no.2 and no. 3 drafts I didn't use an actual IAP-loader code which would be able to reprogram the FLASH memory. In order to do that, I would need to have the new version of tolpc extended with the IAP programming functionality available on the master computer. Sadly, it is still not availiable. Mr Svoboda promised to code it but lately he has been busy with other projects and hasn't had the time to do it yet.
In place of the actual IAP-loader I have, therefore, used only a simple placeholder program which only blinked with the LEDs and sent some test messages over the serial interace.
When I will get around to implementing the actual IAP-loader, I will have to solve one specific problem - What to do with the parts of code that are common between IAP-loader and the rest of the firmware? The simples solution would be to just place it all, together with the IAP-loader, into RAM on runtime. That is ,however, provided that it will all fit in there together with all of the buffers, arrays and other variables. If not, I foresee a lot of work with function pointers and memory overlays and such when I will have to figure out how to make it all fit somehow. We will not find out how it goes until we try it though.

Measuring the current

I have also been encouraged to start working on the following task on my list, which is upgrading the current firmware to enable it to measure the current running through the four coils which are present on each MagMan module. Everything on the hardware side is already, wired and prepared for this; It is just that nobody has yet had the time to program it.
So far I have only done some reading on how the ADC works but I can already tell that, while implementing this feature, I wil have to make a lot of decisions about how it's all going to operate. For example:

• What sampling frequency to use?
• Whether to use stroboscopic sampling.
• Define new Elvis messages to control the sampling process and to read the data from the modules.
• Decide how often to read the data and how to store it in between the reads.
• Whether to do any pre-processing on the data.

So, as always, there is not a shortage of work for me.
Write to you next week!