Peter
Could you detail how you envisabe the checking of the software on the TFTP server?
Your board will be operating as a client and has the ability to perform a read or a write but not request information about the files there. Do you envisage reading a standard named file and comparing its content? If the content doesn't match that loaded on the board then deleting the boards code and reading the file again?
Regards
Could you detail how you envisabe the checking of the software on the TFTP server?
Your board will be operating as a client and has the ability to perform a read or a write but not request information about the files there. Do you envisage reading a standard named file and comparing its content? If the content doesn't match that loaded on the board then deleting the boards code and reading the file again?
Regards
Peter
I am sure that the NicheLite stack (as other free or open source ones) includes the protocols needed so it would be possible to patch up something after adding the necessary in circuit FLASH routines (IAP).
You can also look at the uTasker solution which is designed for the M5223X (free for non-commercial work). It is a 2k boot loader (one FLASH sector in the M5223X) and it allows complete software updates via Internet (I say Internet rather than LAN because it has secure upload capabilities based on HTTP POST methods and doesn't need a server as TFTP does).
It may be that this doesn't suit but you could look at it to be sure (it is documented here):
http://www.utasker.com/docs/uTasker/uTaskerBootLoader.PDF
http://www.utasker.com/docs/uTasker/BM-Booloader_for_M5223X.PDF
You will see that it requires application support (to allow the transfers using TCP based methods) before the application, OS and stack are replaced by the loader) and so needs enough space to store the new program alongside the old one. [The file system supports also saving in cheap external SPI based memory for such jobs which is an interesting approach when FLASH is restricted].
The uTasker bootloader doesn't have a configuration (at present) for a TFTP based transfer but the components are available if you would like to "plug them together"...
The disadvantage of having TFTP [IP, ARP, UDP] and DHCP [plus IAP] in the boot loader is that it will probably require about 16k of FLASH on the M5223X - see code size comparisons here:
http://www.utasker.com/docs/M5223X/uTaskerV1.2-Tutorial-M5223X.PDF (page 15)
A further approach is to include the OS and TCP/IP stack in the bootloader [disadvantage is that these elements can not be updated via LAN - only the application can be or parts of the others 'patched'], then the size of the boot loader is not an issue. The application parts make use of the same resources (eg. OS, Stack, File system etc.) after it has been loaded. The uTasker has what we call MULTISTART support - it enables an application (or additional applications) to be uploaded to the board and the system reconfigures itself to schedule the new software parts. In other words it can function as an application specific boot loader using what ever methods are required.
PS: Have you tried stripping down the dBug code (it is available as source) to see how small it can be made?
Regards
I am sure that the NicheLite stack (as other free or open source ones) includes the protocols needed so it would be possible to patch up something after adding the necessary in circuit FLASH routines (IAP).
You can also look at the uTasker solution which is designed for the M5223X (free for non-commercial work). It is a 2k boot loader (one FLASH sector in the M5223X) and it allows complete software updates via Internet (I say Internet rather than LAN because it has secure upload capabilities based on HTTP POST methods and doesn't need a server as TFTP does).
It may be that this doesn't suit but you could look at it to be sure (it is documented here):
http://www.utasker.com/docs/uTasker/uTaskerBootLoader.PDF
http://www.utasker.com/docs/uTasker/BM-Booloader_for_M5223X.PDF
You will see that it requires application support (to allow the transfers using TCP based methods) before the application, OS and stack are replaced by the loader) and so needs enough space to store the new program alongside the old one. [The file system supports also saving in cheap external SPI based memory for such jobs which is an interesting approach when FLASH is restricted].
The uTasker bootloader doesn't have a configuration (at present) for a TFTP based transfer but the components are available if you would like to "plug them together"...
The disadvantage of having TFTP [IP, ARP, UDP] and DHCP [plus IAP] in the boot loader is that it will probably require about 16k of FLASH on the M5223X - see code size comparisons here:
http://www.utasker.com/docs/M5223X/uTaskerV1.2-Tutorial-M5223X.PDF (page 15)
A further approach is to include the OS and TCP/IP stack in the bootloader [disadvantage is that these elements can not be updated via LAN - only the application can be or parts of the others 'patched'], then the size of the boot loader is not an issue. The application parts make use of the same resources (eg. OS, Stack, File system etc.) after it has been loaded. The uTasker has what we call MULTISTART support - it enables an application (or additional applications) to be uploaded to the board and the system reconfigures itself to schedule the new software parts. In other words it can function as an application specific boot loader using what ever methods are required.
PS: Have you tried stripping down the dBug code (it is available as source) to see how small it can be made?
Regards
