Internet Explorer 8 is not compatible with the link (IE 8 loses the scroll bars for some reason and so it is recommended to use Firefox or Chrome or other well behaved browsers ;-).
FLASH
The LPC23xx has up to 512k internal FLASH memory. In the case of the 512k part, the last 8k are not useable since they are required by the internal boot loader.
Now I do have a small advantage here due to the fact that I have used the FLASH in the LPC21xx range of processors a few years ago and also wrote a production loader which communicates with the internal boot software, checks its version number, loads a new version if it find that the original one is too old, and then loads the application code. At the time I knew most of what was needed to know. Since that was however about 3 years ago I have had to re-read to get up to speed again.
Before continuing with porting the uFileSystem to work together with the LPC23xx internal flash it is worth mentioning some details which were made available from a Philip’s application engineer, which give some extra details to understanding how the FLASH is special and some of its restrictions. I have never seen these details in the normal data sheets or users’ manuals but recommend anyone new to the FLASH in the device to check it out! See it here: http://tech.groups.yahoo.com/group/lpc2000/message/2681
Before getting started with the real work, there are two things which will certain cause some complications:
1 - The FLASH granularity is quite large and the actual size varies with the sector number. This makes for some complications because the file system may need to know that granularity is not fixed (all other chips supported up to now have had a fixed FLASH granularity – eg. 256 bytes in the SAM7X up to 64k in the STR91). The first few sectors in the devices are 4k in size, followed by a few 32k sized sectors. The 512k version then has some further 4k sectors towards the end of the FLASH memory range. The large granularity option (sub-file system) in the uTasker project will probably have to be activated for this device.
2 – Data in lines of 16 bytes can not be modified after being written (due to ECC bits in each line). This means that the strategy of marking blocks as being valid will have to be changed to respect this.
3 - Each 4k aligned area can only be written to a maximum of 16 times before it must be erased. I don’t know whether this cause a problem at the moment…
4 – Flash should be programmed in 256 byte blocks (or some larger multiples of this), whereby unaltered bits are best programmed with ‘1’ even if they are already ‘0’.
All in all the FLASH is a little bit trickier to use than in most other chips.
In order to simplify the operation with the FLASH, a fixed 256 byte buffer was set up in RAM to use as preparation and write buffer.
In Application Programming (IAP)
The chip includes pre-installed routines for performing in application programming (writing and erasing FLASH memory). When these routines are operating the FLASH is not accessible, so interrupts are blocked when operation is passed to these functions. In addition, it is important to know that the functions use 32 bytes of memory at the top of internal SRAM – for this reason the stack pointers are not initialised to the top most value in SRAM but 32 bytes below it.
In order to pass operation to the IAP routines execution of its program (at 0x7ffffff0) is started. Parameters to the IAP are passed on the stack and it returns results of its operation on the stack.
The IAP operation was found to work very well and the uTasker simulator was extended to simulate the internal IAP operation, including carefully checking passed parameters and sequences to ensure that any error in use could be immediately seem.
The file system was set up to 176k in size for the first tests, which enabled verification of operation with mixed flash sector sizes (5 x 32k sectors and 4 x 4k sectors). The changes in the file system interface were fortunately quite painless and the sub-file system was found to be suitable.
File writing required holding the first FLASH line (16 bytes – quad word) in a temporary buffer until the end of the file had been reached and its size know. As the file was closed the first line, including MIME information and file length, were saved – this is special due to the FLASH operation as discussed previously. A further advantage of file writing is that the writes are always sequential (apart from at the end); that means each byte is simply at the next address (they don’t jump around). This made the management of the FLASH row buffer and the commits to FLASH quite simple; every time a FLASH row boundary was passed the buffer could be written. Right at the end of the file, any open buffer could be additionally committed. After testing FTP and HTTP in the uTasker simulator (and of course implementing and debugging the integration of the new FLASH driver) it was time to give it a shot on the hardware. This worked first time so I moved on to the parameter system, thinking that the work was practically over.
Now the parameter system did in fact prove to be a little more complicated than expected. Not due to the fact that its operation was more difficult but due to the fact that a decision had to be made about how best to implement it, based on the fact that bytes can not be modified at any address – the rule about the 16 byte line again…
Since the purpose of the parameter system is no for absolute efficiency but rather for highest reliability, where the user can modify system parameters either in a temporary or permanent way with the security that no data can be lost - even if there is a power down during the sequence – there was really only one way to do it. This was to use one FLASH line (16 bytes) to save each byte of user parameter data. This is very inefficient since only 256 bytes of user parameter data can be saved in a 4k FLASH sector (the smaller ones are of course pre-destined for this use – I configured the last 2 to work as a swap block). This does however allow random writes to be made to the parameter system, which is important as its use is not sequential as is file access. It hurts to be so wasteful of memory but on the other hand it is good to know that the parameter system remains bullet proof, which is the most important point.
To avoid unnecessary writes, additional checking code was added to not write unmodified data to the internal FLASH. This reduces actual write cycles to the minimum required and so should avoid any issues of maximum writes before deletion. The swap buffers always delete when tidying up after adding new parameter data which fits well.
So with that exercise behind me I activated a few more services like SMTP to perform email tests and an HTTP GIF image upload test and have put the LPC2378 board on line to see how it performs.