Ethernet boot-loader for the LPC23XX

[mark]

Hi All

I am very proud to inform you that today I completed a boot loader (the uTasker Bare-Minimum-Bootloader) for the LPC23XX. It allows complete firmware upgrades via Ethernet (using FTP or HTTP post) and occupies one 4k FLASH sector, taking up about 2k of actual space (about 2.9k when encrypted upload is enabled).

I tested on the MCB2300 with a 336k file system configured, where the last 136k of it is reserved for accepting the new firmware. This is a useful configuration since this allows a fairly big code with 200k of web pages, a parameter system to comfortably work on the chip and remote upgrades to be made via the Internet without any need for external support (eg. using SPI FLASH).

The development took place purely using the uTasker simulator until I was reasonably sure that the operation was correct. The first test on the target failed because of the boot loader being linked using the false linker script file... the second attempt worked so I was very happy (and a little relieved).

The only thing that I am a little unsure of is the time it takes for the actual programming it complete (check of the new code, delete of old code, programming of new code to program space and delete of the back-up) taking around 9s. I don't program the PLL during this operation so it is running (I believe) directly from the 12MHz crystal. I am wondering whether there would be an improvement in running the PLL at full speed or whether the time lost is waiting for the FLASH operations to complete (which is probably not clock speed dependent).

I set up the bootloader project using Rowley to fit together with the Rowley uTasker build seeing as this is proving to be the most popular development environment for this chip.

Since the development version now includes the boot loader and SPI FLASH support for both ATMEL and ST devices I do believe a new service pack would be very worth while - a little new documentation is required but this could be ready quite shortly!!

Regards

Mark

Note: I also checked everything on the OlimexLPC-2378-STK and it worked correctly. On this board the reprogramming time was about 12s - I wonder why the difference? The actual uTasker demo project is around 55k in size and so the actual upload time via LAN is hardly noticable (almost instantaneous).

[boB]

Hi Mark, thanks for turning me on to this great new (to me anyway) forum ! (through LPC2000 Yahoo)

Could you possibly find out where all the time is being spent by taking a spare I/O pin,
and setting it high when you go into a section of code and reset it low when it leaves
that section and look at it with a scope ?  Then, when you're satisfied that one particular
part of code isn't the bottleneck, put the pin toggling somewhere else and look again.
This is one trick I use for just this kind of thing. i.e., is it the programming ?  Filling
the buffer through the ethernet ?  erasing ?  Some weird loop you didn't think about
before ?  I sometimes find very weird and unexpected reasons for things to not work by
this method.


I'm JUST now (today in fact) starting to learn about the LPC23XX series after using
the LPC2103 and LPC214X parts for a while now.

good luck.

boB

[mark]

Hi Bob

Welcome to the forum and thanks for your ideas.
I did do as you suggested, but only after checking the clocking details because my main concern was with 'frying' the chip by using false clock settings when programming. It turned out (as I now believe to be the true case) that the internal 4MHz RC oscillator was being used rather than the external 12MHz crystal, which would have meant some overprogramming - however with the correct settings it didn't make any noticable difference in the speed.

The measurements that I made showed then the following situation:
- Check of new code and CRC-16 took 2.5s for 55k new code size
- Delete of old code took 0.6s
- Programming of new code took 3s (including copying it)
- Check of newly programmed code and CRC-16 took 3s
- delete of backup of new code took 0.5s

Therefore the FLASH operations were not that significant, but rather the processing speed (4MHz and without MAM acceleration) was the bottle-neck.

Since the project code supports PLL configurations, starting from either non-configured or already connected, I decided to set this to max. when doing the checking and copying functions. Without optimised MAM settings it then took about 2s. With optimised MAM (partially-active) it was then about 1.5s.

During the process I did find a problem with the optimisation of the GCC compiler causing PLL setup register access order to be inverted at one critical location, which resulted in some strange effects during first tests, but ensuring that PLLCON is specified as volatile solved it.

The result is that firmware upgrades are now really QUICK!! Between pushing the upload button in the browser and seeing the new code communicating there is a delay of around 4s (including a 2s pause before the board actually commands the reset for the copy). I can certainly live with that!!!

Best regards

Mark

[paul_l_curtis]

Hi Bob

Welcome to the forum and thanks for your ideas.
I did do as you suggested, but only after checking the clocking details because my main concern was with 'frying' the chip by using false clock settings when programming. It turned out (as I now believe to be the true case) that the internal 4MHz RC oscillator was being used rather than the external 12MHz crystal, which would have meant some overprogramming - however with the correct settings it didn't make any noticable difference in the speed.

I believe that the processor speed is not required on the new LPC2k chips, only the old 210x chips absolutely required the CCLK to be known to calibrate delay loops.  I now believe status bits are polled in the IAP routines and, hence, speed is mostly irrelevant.

The LPC21xx series can reprogram 512K in about 2s with the PLL enabled.  The LPC23xx series is about 1/2 that speed (I have no idea why).

Do you use a moderately fast CRC16?  I wonder because our CRC32 verifies flash at about 700Kbytes/second at 60MHz...

-- Paul.

[mark]

Hi Paul

It think that it is bog-standard CRC-16 as follows:

Code: [Select]

// CRC-16 routine
//
extern unsigned short fnCRC16(unsigned short usCRC, unsigned char *ptrInput, unsigned short usBlockSize)
{
    while (usBlockSize--) {
        usCRC = (unsigned char)(usCRC >> 8) | (usCRC << 8);
        usCRC ^= *ptrInput++;
        usCRC ^= (unsigned char)(usCRC & 0xff) >> 4;
        usCRC ^= (usCRC << 8) << 4;
        usCRC ^= ((usCRC & 0xff) << 4) << 1;
    }
    return usCRC;
}
Regards

Mark