11
« on: February 16, 2008, 10:42:29 PM »
Hi Mark,
I am having lots of fun playing with uTasker and it various capabilities! I find as I go I am learning a lot and correcting some misunderstandings I have been harbouring since starting my evaluation.
One particular misunderstanding I have had, I think, is regarding the file system and application.
Correct me if I am wrong, but the application does not live in the file system, does it?
I think my task creating a bootloader for NE64 is now simplified.
In config.h, I can define SPI_FILE_SYSTEM and not define FLASH_FILE_SYSTEM. That way files uploaded to the NE64 get written to a 64K external SPI EEPROM while the application still runs out of internal FLASH as usual. The drawback is the 16k reserved for internal file system is not available for files. (But I suppose it frees up 16k for application code, correct?) Reading the documentation again seems to state this quite clearly - I am not sure how I missed it!
So ignoring the complications with interrupts as we discussed previously, would it not be possible to have the firmware upgrade process work as follows (using the releases code for NE64 uTasker SP1):
1. Start with programming via BDM the blank NE64 FLASH with the applicatin - EEPROM is blank.
2. Run the application, connect with TFTP (rather than FTP since TFTP takes dramatically less resources).
3. uTasker receives webpage files and stores them to SPI EEPROM.
4. Webpages are now active and can be browsed.
5. Some time later, we want to do a firmware upgrade.
6. Connect via TFTP and transfer a new application file. The file gets written to the file system on EEPROM, as usual.
7. Reboot. (What follows will be standard boot process regardless of firmware upgrade or not)
8. Bootloader, which I've developed, checks the EEPROM for a valid application which has been predefined to start at a certain address. If found, copy the file to internal FLASH. If not found, jump to application in FLASH. The application in EEPROM can be erased by the bootloader, or by the application at startup.
9. User reconnects via TFTP and transfers new webpages, if required. (If new applicaiton is less than 48k, webpages stored in EEPROM remain intact. so no webpage transfer is required)
6a. Alternative to step 6. Rather than TFTP, a webpage can provide this functionality, as long as application is less than 48k so that webpages do not have to be erased.
Does this seem like the best approach, after the other scenarios that we've discussed?
Your comments are greatly appreciated!
Jamie