• AVR Freaks

Hot!Programming via Ethernet interface?

Page: 12 > Showing page 1 of 2
Author
Datman
Starting Member
  • Total Posts : 74
  • Reward points : 0
  • Joined: 2006/01/25 16:46:45
  • Location: 0
  • Status: offline
2007/03/07 17:13:36 (permalink)
0

Programming via Ethernet interface?

Hi guys. we have a project on the go where we would like be able to upgrade firmware ( reporgram the micro ) via an ethernet interface. Currently we use Lantronix Xports as an ethernet inerface for some of our electronics. This device interfaces serially to the microcontroller, then ethernet to the outside world..
 
http://www.lantronix.com/device-networking/embedded-device-servers/xport.html
 
We would like to have a simple web applet that a customer can simply plug in a cat 5 ethernet cable to our device, and upgrade the software in the micro. Is something like this possible with PIC microcontrollers? It is something we have never done before, any info would be much appreciated. I have sifted through all the info on programming a PIC device using ICSP, and am utterly confused. We are as yet unsure which micro we will use, something from the 8 bit range.
 
any clues, pearls of wisdom??
#1

33 Replies Related Threads

    asmallri
    Super Member
    • Total Posts : 1864
    • Reward points : 0
    • Joined: 2004/05/26 09:00:05
    • Location: Perth, Australia
    • Status: offline
    RE: Programming via Ethernet interface? 2007/03/07 17:23:54 (permalink)
    0
    If you are looking at an alternative Ethernet solution using a  PIC with Embeded Ethernet, such as the PIC18F97J60, or marrying a PIC with an Ethernet controller such as a Microchip ENC28J60 or the Realtek 8019AS, then I sell the source code for Ethernet bootloaders for these platforms.

    The programming application is a PC application written in Delphi (image and source supplied).

    If using a PIC with an external Ethernet controller for generic network applications then I suggest selecting a PIC with at least 64K of Program Memory and as much RAM as possible. Examples include PIC18F2620/4620/8722 (and family members). For relatively simple network applications not requiring a full IP stack implementation DHCP/HTTP/FTP etc, you can use a smaller PIC.

    Regards, Andrew

    http://www.brushelectronics.com/index.php?page=software
    Home of Ethernet, SD Card, and Encrypted Serial and USB Bootloaders for PICs!!
    #2
    ric
    Super Member
    • Total Posts : 22310
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: offline
    RE: Programming via Ethernet interface? 2007/03/08 01:19:20 (permalink)
    0
    ....or,
    If you continue using the XPORT, you could just use a serial bootloader in the PIC.

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #3
    Olin Lathrop
    Super Member
    • Total Posts : 7463
    • Reward points : 0
    • Joined: 2004/02/26 17:59:01
    • Location: Littleton Massachusetts
    • Status: offline
    RE: Programming via Ethernet interface? 2007/03/08 06:17:15 (permalink)
    0
    Hi guys. we have a project on the go where we would like be able to upgrade firmware ( reporgram the micro ) via an ethernet interface. Currently we use Lantronix Xports as an ethernet inerface for some of our electronics. This device interfaces serially to the microcontroller, then ethernet to the outside world.

    Sounds like a good application for a bootloader, depending on the PIC you are using.  Not all PICs can write to their own program memory.
     
    But since you are looking into ICSP I may be confused about your requirements.  A bootloader would have nothing to do with ICSP.  Are you looking for a totally separate external ethernet port the customer would plug into to reprogram the main controller PIC?  If so, that may likely be more complex than your original project you want to add this capability to.  We have experience with external and embedded ICSP programmers, but again, a bootloader would be the first solution to look into.
    #4
    jesseg
    Senior Member
    • Total Posts : 122
    • Reward points : 0
    • Joined: 2006/08/02 09:20:22
    • Location: 0
    • Status: offline
    RE: Programming via Ethernet interface? 2007/03/08 09:45:26 (permalink)
    0
    Datman,

    I've played around with the lantronix device -- it's pretty neat. What you most likely want to do is use a serial bootloader, like the other fellows suggested.

    Probably ICSP isn't what you're interested in, since it involves a special syncronous (clocked) serial protocol. You actually could implement ICSP using an xport device and a serial to parallel shift register and some other glue logic so you could bit-bang a virtual ICSP programmer protocol over the ethernet, but it would be slow and a lot of work. But it would allow you to upgrade your PIC with no bootloader, and to program it for the first time via ethernet. On the other hand, a bootloader would require no extra glue logic, but would require that the bootloader be burned in using a regular ICSP programmer like ICD2 or whatever, before the firmware could be updated via ethernet.

    In general, a serial bootloader is a small program that you first program into all of your PIC micros. It listens on the RS232 port, and when a certain sequence of bytes comes to the PIC over the serial port, it programs them into memory (but of course it doesn't overwrite itself.) The bootloader generally resides in the first few dozen or hundred bytes of program memory, probably in the boot-block. (I think it would reside in the bootblock anyway..)

    bootloader programs come in all sizes, all the way from simplistic with no error checking, which take as input simple raw data and take up a few dozen bytes, to complex where they have ample error and verify checking and can take in actual hexdump files, decode them, and write them. (Decoding an arbitrary hexdump file with limited ram and programming it's contents to the right place can be tricky.)

    In your specific case, you would use the xport to translate a TCP stream into an RS232 stream, which would then be sent to the PIC. If you had a special program that could just send the new firmware over a TCP connection, then your bootloader could be a pretty simple one.

    But it sounds like you probably don't want the person performing the firmware upgrade to have to install any application on the workstation in order to perform the upgrade.

    You have a couple of options: One is that the person performing firmware upgrade can go to a certain webpage on the internet where a javascript or java app loads into the browser and then initiates a connection to the device to be upgraded, and sends it special commands over a TCP connection to the wiport.

    Another option would be to implement an extremely tiny web-server into your bootloader, that supports the HTTP POST method of submitting large quantities of data. Then, to upgrade the firmware, the operator would simple point any standard web browser (with no need for java or the script [not] thereof) to the IP of the PIC device's xport, and click the option to "Upload new firmware" (browsers support uploading files using POST.)

    One possible problem with this latter idea is that if it took a whole minute or more for the programming process to take place, the browser might give up. But my limited experience with bootloaders is that they are super fast compared to ICSP.

    I suggest using an 18F pic part if you can, because they have more cool instructions then 16F and they also can work with bootloaders.

    Hope this helps,

    -Jesse

    PS: One problem with poorly written bootloaders is that if the PIC config fuses are incorrectly set, the bootloader may have the ability to get confused and erase or destroy itself, making further ethernet upgrades impossible until the unit has been sent back to have a normal ICSP upgrade done to it. But this should not be a problem if it's in the bootblock, and the bootblock is correctly write protected, or whatnot. Perhaps other smarter folks here could comment on this problem since I don't know much about it.
    post edited by jesseg - 2007/03/08 09:49:35
    #5
    Olin Lathrop
    Super Member
    • Total Posts : 7463
    • Reward points : 0
    • Joined: 2004/02/26 17:59:01
    • Location: Littleton Massachusetts
    • Status: offline
    RE: Programming via Ethernet interface? 2007/03/08 10:36:12 (permalink)
    0
    The bootloader generally resides in the first few dozen or hundred bytes of program memory, probably in the boot-block.

    It can, but I wouldn't say "generally".  I have so far always put my bootloaders at the end of memory because I wanted the app to own the interrupt vector.
     
    bootloader programs come in all sizes, all the way from simplistic with no error checking, which take as input simple raw data and take up a few dozen bytes, to complex where they have ample error and verify checking and can take in actual hexdump files, decode them, and write them.

    Verification is important in a bootloader.  If the app gets corrupted and ever gets control, the device could be totally dead from the customer's point of view.  You don't want a simple data error or interrupted power or communications during the bootload process to turn your device into a brick.  I usually add a checksum to the app image, and the bootloader won't run the app unless the checksum checks.  If the app got written half way then power cycled, the checksum would not match.  The device won't perform normal operations, but at least it will be possible to upload a clean app image and recover.
     
    Decoding an arbitrary hexdump file with limited ram and programming it's contents to the right place can be tricky.

    That's why this should be done on the host where it's trivial.  The host should send a simple data stream that is as easy to decode as possible.  It's no hardship on the host to require it to send all data in order without skipping sections, for example.
     
    But my limited experience with bootloaders is that they are super fast compared to ICSP.

    Then you must be using very slow ICSP programmers.
    #6
    Datman
    Starting Member
    • Total Posts : 74
    • Reward points : 0
    • Joined: 2006/01/25 16:46:45
    • Location: 0
    • Status: offline
    RE: Programming via Ethernet interface? 2007/03/08 12:26:07 (permalink)
    0
    ORIGINAL: jesseg


    But it sounds like you probably don't want the person performing the firmware upgrade to have to install any application on the workstation in order to perform the upgrade.

    You have a couple of options: One is that the person performing firmware upgrade can go to a certain webpage on the internet where a javascript or java app loads into the browser and then initiates a connection to the device to be upgraded, and sends it special commands over a TCP connection to the wiport.

    Another option would be to implement an extremely tiny web-server into your bootloader, that supports the HTTP POST method of submitting large quantities of data. Then, to upgrade the firmware, the operator would simple point any standard web browser (with no need for java or the script [not] thereof) to the IP of the PIC device's xport, and click the option to "Upload new firmware" (browsers support uploading files using POST.)


    -Jesse

     
    Thanks very much jesseg you have hit the nail on the head, this is exactly what I want. As I say this is all completely new to me, I have never used bootloaders. Thanks for explaining how it works guys. So it sounds like it is at least possible, which is a start! The other reason we want a web interface is so that the user can set parameters and thresholds for the circuit by simply connecting to the ethernet port. This is a seperate issue though which we have a fair idea on how to achieve.
    #7
    jesseg
    Senior Member
    • Total Posts : 122
    • Reward points : 0
    • Joined: 2006/08/02 09:20:22
    • Location: 0
    • Status: offline
    RE: Programming via Ethernet interface? 2007/03/08 12:41:10 (permalink)
    0
    quote:

    The bootloader generally resides in the first few dozen or hundred bytes of program memory, probably in the boot-block.

    It can, but I wouldn't say "generally".  I have so far always put my bootloaders at the end of memory because I wanted the app to own the interrupt vector.

    Thanks, Olin. That's a good point: The interrupt vectors are near the begining of program memory, so if  your bootloader is at the begining of program memory, it has the advantage of being guaranteed to run first, but that also means that the interrupt routine is delayed by a couple instructions worth each time it's called because the interrupt vector is just a GOTO to the actual ISR which is residing someplace else. So in a high performance situation where a slight constant delay entering the ISR is a problem, you certainly want the bootloader not at the very begining.

    None the less, Microchip does put in their 18F series pics something they describe as a "boot block, which is a small section of protectable program memory allocated specifically for bootload firmware." Incidently, I have not actually figured out exactly what's so special about the boot block. But microchip insists that it's a special feature specifically for bootloaders. And it resides at the very begining of the program memory. Olin/Ric/whoever: What is special about the bootloader? Thanks!

    Datman, you might check out this article for Microchip's introduction to boot loaders along with example assembly and PC application.

    The reason it's important for the bootloader to run first and for it to be in a read-only section (like the bootblock) is so that no matter what happens to the rest of your code, as long as your config fuses are correctly set so the PIC can run, the bootloader can always run first and re-program the rest. And if the bootloader is read-only, then it cannot damage itself.


    quote:

    But my limited experience with bootloaders is that they are super fast compared to ICSP.

    Then you must be using very slow ICSP programmers.


    Yup! I was, at that time, using a printer port DIY programmer, which was much slower then a bootloader running at 115k2 bps RS232!

    Thanks,

    -Jesse

    #8
    asmallri
    Super Member
    • Total Posts : 1864
    • Reward points : 0
    • Joined: 2004/05/26 09:00:05
    • Location: Perth, Australia
    • Status: offline
    RE: Programming via Ethernet interface? 2007/03/08 12:42:25 (permalink)
    0
    ORIGINAL: jesseg
    Another option would be to implement an extremely tiny web-server into your bootloader, that supports the HTTP POST method of submitting large quantities of data.


    This approach is very complex for a bootloader requiring the PIC to not only handle the typical bootloader tasks but to implement a deep stack. TCP add unnecessary complexity to a bootloader never mind about also supporting HTTP. Forget about the PIC for a moment, If you look at typical network boot protocols, such as bootp or DHCP option 57, thesy are built on UDP because of the smaller memory (program and ram) and CPU cycles. If you read the RFC on bootp you will see mention of this.

    PS: One problem with poorly written bootloaders is that if the PIC config fuses are incorrectly set, the bootloader may have the ability to get confused and erase or destroy itself, making further ethernet upgrades impossible until the unit has been sent back to have a normal ICSP upgrade done to it.


    This is very easy to fix - the bootloader does not set fuses for the application. This  limitation is normally not a problem because you set the fuses to match the hardware environment. This environment is the same one the bootloader runs in.

    But my limited experience with bootloaders is that they are super fast compared to ICSP.


    This matches my experience.

    Then you must be using very slow ICSP programmers.


    The Ethernet bootloader is significantly faster than using an ICD2. Because a bootloader can be an incremental bootloader, the bootloader can, an often does, finish the programming task before the ICD2 has decided it is connected to the correct target. I suspect any incremental programmer would beat the ICD2 hands down.
    post edited by asmallri - 2007/03/08 12:54:49

    Regards, Andrew

    http://www.brushelectronics.com/index.php?page=software
    Home of Ethernet, SD Card, and Encrypted Serial and USB Bootloaders for PICs!!
    #9
    jesseg
    Senior Member
    • Total Posts : 122
    • Reward points : 0
    • Joined: 2006/08/02 09:20:22
    • Location: 0
    • Status: offline
    RE: Programming via Ethernet interface? 2007/03/08 12:54:20 (permalink)
    0
    ORIGINAL: asmallri

    ORIGINAL: jesseg
    Another option would be to implement an extremely tiny web-server into your bootloader, that supports the HTTP POST method of submitting large quantities of data.


    This approach is very complex for a bootloader requiring the PIC to not only handle the typical bootloader tasks but to implement a deep stack. TCP add unnecessary complexity to a bootloader never mind about also supporting HTTP. Forget about the PIC for a moment, If you look at typical network boot protocols, such as bootp or DHCP option 57, thesy are built on UDP because of the smaller memory (program and ram) and CPU cycles. If you read the RFC on bootp you will see mention of this.

    Thanks for the input, Andrew!

    Incidently, Datman already has an xport in there which is an ethernet to RS232 module (by lantronix.com). It functions as a bridge between a TCP connection and a simple plain RS232 stream, so for all practical purposes, the ethernet part can be more or less ignored. The only protocol the PIC would have to implement would be HTTP -- which, in it's most simple (and probably not RFC compliant but functional form) can be very simple, very easily dealt with in a simple assembly bootloader.

    PS: One problem with poorly written bootloaders is that if the PIC config fuses are incorrectly set, the bootloader may have the ability to get confused and erase or destroy itself, making further ethernet upgrades impossible until the unit has been sent back to have a normal ICSP upgrade done to it.


    This is very easy to fix - the bootloader does not set fuses for the application. This  limitation is normally not a problem because you set the fuses to match the hardware environment. This environment is the same one the bootloader runs in.


    I agree, writing config fuses from a bootloader probably isn't a good idea. But since brown-out voltage and other settings are set in config fuses, it may be needed sometimes.

    Datman: The reason setting config fuses from a bootloader is a bad idea is because if it were to set the OSC mode to something that didn't work (like xtal mode when there was no xtal) or whatever, then the PIC would be unable to run anymore, which would prevent the firmware from being upgraded or fixed via bootloader, and would require a regular ICSP reprogramming.

    -Jesse
    post edited by jesseg - 2007/03/08 12:56:12
    #10
    Olin Lathrop
    Super Member
    • Total Posts : 7463
    • Reward points : 0
    • Joined: 2004/02/26 17:59:01
    • Location: Littleton Massachusetts
    • Status: offline
    RE: Programming via Ethernet interface? 2007/03/08 13:10:03 (permalink)
    0
    The interrupt vectors are near the begining of program memory, so if  your bootloader is at the begining of program memory, it has the advantage of being guaranteed to run first, but that also means that the interrupt routine is delayed by a couple instructions worth each time it's called because the interrupt vector is just a GOTO to the actual ISR which is residing someplace else. So in a high performance situation where a slight constant delay entering the ISR is a problem, you certainly want the bootloader not at the very begining.

    It's not just about performance.  You want to be able to update the whole app, which includes the interrupt routines.  If the vectors are in the bootloader area then either the interrupt routines must be at fixed known locations or the short code at the vectors must be updatable along with the main app image.  This allowing overwrite in several disjointed regions makes the bootloader more complex and with a bigger chance of a bug.
     
    With the bootloader at the end of memory the app image is one contiguous region from a little past the reset vector up to the start of the bootloader.  It just makes things simpler.
     
    Incidently, I have not actually figured out exactly what's so special about the boot block.

    I think it's mostly a security thing.  There are usually separate code protection and related bits just for the boot block.  In a high security application you want all the hardware vectors protected.
     
    And if the bootloader is read-only, then it cannot damage itself.

    Which is pretty easy to ensure with proper code anyway.  I think the main issue is that the app can't damage the bootloader.  However this also means that it is impossible to ever update the bootloader.  So far I have left all my bootloaders unprotected so that updating the bootloader is possible, although it need not be easy.  This has come in handy more than once, although it is a slight risk.  So far in my experience being stuck with a bootloader that can't be updated has been a bigger risk than the application accidentally writing on the bootloader.  This is not something that is likely to happen accidentally.
     
    To update the bootloader I temporarily load in a special application that takes over the reset vector, updates the bootloader, verifies it, then updates the reset vector to jump back to the bootloader.  This has so far saved my butt twice.
    #11
    Olin Lathrop
    Super Member
    • Total Posts : 7463
    • Reward points : 0
    • Joined: 2004/02/26 17:59:01
    • Location: Littleton Massachusetts
    • Status: offline
    RE: Programming via Ethernet interface? 2007/03/08 13:15:49 (permalink)
    0
    This approach is very complex for a bootloader requiring the PIC to not only handle the typical bootloader tasks but to implement a deep stack.

    Yes, you don't want to do this unless you have a large PIC.  I implemented just a TCP bootloader (not HTTP) on a 18F6627 using ENC28J60 ethernet, and it took about 28Kbytes at the end of memory.  Actually I reserved 32Kbytes to allow for the bootloader to be bigger if it ever needed to be updated.  The vast majority of this code is the TCP/IP stack.
    #12
    jtemples
    عُضْوٌ جَدِيد
    • Total Posts : 11176
    • Reward points : 0
    • Joined: 2004/02/13 12:31:19
    • Location: Southern California
    • Status: offline
    RE: Programming via Ethernet interface? 2007/03/08 13:30:46 (permalink)
    0

    ORIGINAL: Olin Lathrop

    And if the bootloader is read-only, then it cannot damage itself.

    Which is pretty easy to ensure with proper code anyway.

    And proper hardware. Any system with a bootloader that isn't code-protected and that has the possibility of browning out can destroy the bootloader.
    #13
    jesseg
    Senior Member
    • Total Posts : 122
    • Reward points : 0
    • Joined: 2006/08/02 09:20:22
    • Location: 0
    • Status: offline
    RE: Programming via Ethernet interface? 2007/03/08 14:00:29 (permalink)
    0
    Yes, you don't want to do this unless you have a large PIC.  I implemented just a TCP bootloader (not HTTP) on a 18F6627 using ENC28J60 ethernet, and it took about 28Kbytes at the end of memory.  Actually I reserved 32Kbytes to allow for the bootloader to be bigger if it ever needed to be updated.  The vast majority of this code is the TCP/IP stack.


    Datman, since you're using an xport ethernet to RS232 module, you don't need to worry about TCP/IP stack and your bootloader does not need to be anything fancy. These fellows are talking about how complicated it would be if you did not have  your xport ethernet module in there! But since you have it, you can use a simple bootloader. You will, however, need to use flow-control on the RS232 port, but Xon/Xoff should work fine if you don't want to use extra lines for hardware flow control.

    -Jesse
    #14
    Olin Lathrop
    Super Member
    • Total Posts : 7463
    • Reward points : 0
    • Joined: 2004/02/26 17:59:01
    • Location: Littleton Massachusetts
    • Status: offline
    RE: Programming via Ethernet interface? 2007/03/08 14:24:41 (permalink)
    0
    Any system with a bootloader that isn't code-protected and that has the possibility of browning out can destroy the bootloader.

    I don't know where you got this from.  Low power voltage on a PIC isn't a threat to program memory as far as I know.  All PICs go thru brownout for at least a little while as they are being powered up and down, and I've never observed this causes them to loose bits in program memory.  Maybe you're worried about the PIC executing strangely at low voltages, but it woud be very very unlikely for random instructions to alter program memory.  The unlock sequence has to be followed exactly, and the probability of that happening together with remaining instructions being a meaningful write are vanishingly small.  I think you'd have to worry about your 32 bit checksum before you worry about that.
    #15
    Datman
    Starting Member
    • Total Posts : 74
    • Reward points : 0
    • Joined: 2006/01/25 16:46:45
    • Location: 0
    • Status: offline
    RE: Programming via Ethernet interface? 2007/03/08 15:04:34 (permalink)
    0
    thanks jesseg. It all makes a lot more sense to me now than it did when i started the topic, which is good! Im doing some more research over the next few days, and no doubt ill have more questions then.
    If I go ahead with this type of plan is the PIC going to have to be programmed via ICSP or some other method initially to get the bootloader code into the micro, or is there some method of doing the initial programming in a similar fashion to our firmware upgrade?
    #16
    ric
    Super Member
    • Total Posts : 22310
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: offline
    RE: Programming via Ethernet interface? 2007/03/08 15:14:54 (permalink)
    0
    ORIGINAL: jesseg
    ...
    You have a couple of options: One is that the person performing firmware upgrade can go to a certain webpage on the internet where a javascript or java app loads into the browser and then initiates a connection to the device to be upgraded, and sends it special commands over a TCP connection to the wiport.

    The XPORT already contains a web server, and several 64k pages of FLASH memory to save custom web pages into, so it's simple to embed your java program directly into the XPORT.
     
    ORIGINAL: Datman
    ...
    If I go ahead with this type of plan is the PIC going to have to be programmed via ICSP or some other method initially to get the bootloader code into the micro, or is there some method of doing the initial programming in a similar fashion to our firmware upgrade?
    ...

    Yes, initially the PIC will have to have the bootloader programmed into it using standard ICSP.

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #17
    jtemples
    عُضْوٌ جَدِيد
    • Total Posts : 11176
    • Reward points : 0
    • Joined: 2004/02/13 12:31:19
    • Location: Southern California
    • Status: offline
    RE: Programming via Ethernet interface? 2007/03/08 15:24:03 (permalink)
    0
    ORIGINAL: Olin Lathrop

    Any system with a bootloader that isn't code-protected and that has the possibility of browning out can destroy the bootloader.

    I don't know where you got this from.

    From experience.

    All PICs go thru brownout for at least a little while as they are being powered up and down

    They are not in brownout if they are held in reset.

    Low power voltage on a PIC isn't a threat to program memory as far as I know.

    That is true, as far as I know.

    The unlock sequence has to be followed exactly

    Yes it does.  And the exact sequence is in your bootloader.

    and the probability of that happening together with remaining instructions being a meaningful write are vanishingly small.

    During a brownout, RAM addresses, including the program counter, can take on random values.  If the program counter happens to take on a random value somewhere near the start of your flash write routine, guess what happens?
    #18
    jesseg
    Senior Member
    • Total Posts : 122
    • Reward points : 0
    • Joined: 2006/08/02 09:20:22
    • Location: 0
    • Status: offline
    RE: Programming via Ethernet interface? 2007/03/08 15:24:54 (permalink)
    0
    Yes, you'll need to ICSP the PIC the first time to load the bootloader code.

    However, you can order pre-programmed PICs from some venders (such as digikey.com in the USA) who will preprogram your code into them. Thus, once you got a good bootloader, you could have digikey (or is it microchip?) preprogram them all with your bootloader, so then they could be programmed the first time with your ethernet solution.

    One other thing comes to mind. Doesn't the xport, or some versions of ethernet modules, have a built in scripting language and GPIO (general purpose IO) pins? One could actually implement a PIC programmer into the ethernet module, so it actually did ICSP of the PIC via ethernet....

    Of course you'd have to learn a new software development platform (namely whatever runs in the ethernet module) but it's an idea anyway.

    -Jesse

    #19
    jesseg
    Senior Member
    • Total Posts : 122
    • Reward points : 0
    • Joined: 2006/08/02 09:20:22
    • Location: 0
    • Status: offline
    RE: Programming via Ethernet interface? 2007/03/08 15:36:42 (permalink)
    0
    Olin says: It's not just about performance.  You want to be able to update the whole app, which includes the interrupt routines.  If the vectors are in the bootloader area then either the interrupt routines must be at fixed known locations or the short code at the vectors must be updatable along with the main app image.  This allowing overwrite in several disjointed regions makes the bootloader more complex and with a bigger chance of a bug.


    Well, let's say that the bootloader resides entirely in the space of 0x000 through 0x1FF, and let's assume that the ISR vectors are at 0x008 and 0x018. One would just hardcode a GOTO 0x208 at 0x008 and a GOTO 0x218 at 0x018. Then the user code would reside in one big chunk from 0x200 and beyond, and for all practical purposes, things would be just like if there was no bootloader, accept there would be a 2-cycle (I'm talking about 18F  bootloaders here) delay in all calls to the ISR; Just like when there is no bootloader, 0x218 could be the ISR, or it could be another GOTO. In any case, the ISR would not have to be in the same place between firmware updates, and would easily be updated along with the rest of the program memory.

    Plus there is the added benefits that the bootloader is guaranteed to run first, and that the bootloader may be in the boot block (and I discuss this later) which I'm pretty sure is specially designed for the purpose of housing (and protecting from additional overwrite/corruption) the bootloader.

    Thus I would say that the drawback of having the bootloader first is pretty much just an issue of performance, specifically those two extra instruction cycles used in the goto.

    With the bootloader at the end of memory the app image is one contiguous region from a little past the reset vector up to the start of the bootloader.  It just makes things simpler.

    With the bootloader at the begining of memory, the app images is still one contiguous region from the end of the bootloader all the way to the end of the program memory. That's just as simple; not only is the main program in one contiguous place, so is the bootloader! (Whereas if the bootloader is at the end, then some supporting code for it, specifically at the reset vector, has to be at the begining, and thus, the bootloader is split into two places. Also, if the bootloader is at the end, and somehow the first few words in program memory get overwritten, then it's toast.)

    I think it's mostly a security thing.  There are usually separate code protection and related bits just for the boot block.  In a high security application you want all the hardware vectors protected.


    Hmm. I did as much looking as I have time for, and now I think that the boot block's special protections are not so much for read protection but rather write protection: This datasheet says "By using a bootloader routine located in the protected Boot Block at the top of program memory, it becomes possible to create an application that can update itself in the field."(Paragraph 2, pdf page 8)

    Furthermore, this App note says 'Devices like the PIC18F458 are designed with a designated "boot block", a small section of protectable program memory allocated speficially for bootload firmware.'(Last sentence in first paragraph on first page.) Then, in the last paragraph on PDF page 2, it says "This bootloader is designed to occupy the current designated boot block of 512 bytes (or 256 words) of memory using the recommended options." and "The boot area can be code protected to prevent accidental overwriting of the boot program." (Emph. Mine.)

    Thus I would conclude that the bootblock is clearly intended by microchip to be a safe place to put a bootloader, where it can be specially write-protected, thus preventing it or other code from bing able to overwrite it. It's also located in a place where it's guaranteed to run first.

    Which is pretty easy to ensure with proper code anyway.  I think the main issue is that the app can't damage the bootloader.  However this also means that it is impossible to ever update the bootloader.  So far I have left all my bootloaders unprotected so that updating the bootloader is possible, although it need not be easy.  This has come in handy more than once, although it is a slight risk.  So far in my experience being stuck with a bootloader that can't be updated has been a bigger risk than the application accidentally writing on the bootloader.  This is not something that is likely to happen accidentally.


    As I said, I have only limited experience with using a bootloader. It was in the early days of my PIC learning, and it was an 18F252, and I was using Microchip's bootloader for it. I did find that every now and again as I did my many reprogram-to-debug reprograms via the bootloader, that once in a while the bootloader would die and I'd have to use ICSP to re-program the bootloader. (At that time I did not know anything about bootblock protections and probably would have benefited.) But bootloaders can be damaged (or it may have been my config fuses.)

    To update the bootloader I temporarily load in a special application that takes over the reset vector, updates the bootloader, verifies it, then updates the reset vector to jump back to the bootloader.  This has so far saved my butt twice.


    Yeah, I was going to say, you'll need a second bootloader, or a second copy of the bootloader to reprogram the main bootloader. But that's pretty clever to have a second temp bootloader for reprogramming the main bootloader! It just doesn't seem right to try to reprogram the very code location that's executing the instruction :-). I guess your secondary bootloader doesn't use any interrupts while it's writing to 0x8 or whatever the interrupt vector is.


    But I would say that hopefully, with a simple bootloader, it wouldn't ever need  updating. (But I sure can see the likelihood of needing to update a complicated bootloader, such as one that supports a full TCP stack..!)

    -Jesse
    #20
    Page: 12 > Showing page 1 of 2
    Jump to:
    © 2019 APG vNext Commercial Version 4.5