| View previous topic :: View next topic |
| Author |
Message |
overmindx
Joined: 06 Oct 2008
Posts: 43
|
| Over the air programming via gprs |
 Posted: Sun Feb 05, 2012 9:52 pm |
 |
|
Hi everybody,
I have a datalogger project which uses an 18f67k22 mcu and it would be deployed remotely. It also has a gsm/gprs daughterboard integrated in it to be used for the transmission of data to our central server.
In case I made improvements in my firmware, is it possible to download the new code to the mcu wirelessly via GPRS? With this, I need not go to the site anymore just to program the mcu.
Please help. Any advice would be greatly appreciated.
Thanks |
|
 |
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Mon Feb 06, 2012 2:47 am |
|
|
| Possible yes. Most people doing similar things are preferring a storage device, e.g. serial flash to allow complete donwload and verification of the firmware image before programming it. |
|
|
asmallri
Joined: 12 Aug 2004
Posts: 1634
Location: Perth, Australia
|
| Re: Over the air programming via gprs |
| Posted: Mon Feb 06, 2012 7:11 am |
|
|
| overmindx wrote: | Hi everybody,
I have a datalogger project which uses an 18f67k22 mcu and it would be deployed remotely. It also has a gsm/gprs daughterboard integrated in it to be used for the transmission of data to our central server.
In case I made improvements in my firmware, is it possible to download the new code to the mcu wirelessly via GPRS? With this, I need not go to the site anymore just to program the mcu.
Please help. Any advice would be greatly appreciated.
Thanks |
Depending on the gsm/gprs type and operating mode, the data logger may be presented to the server as a "directly connected" device over a serial interface. If this is the case then a typical serial bootloader will do the job.
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
|
| Posted: Mon Feb 06, 2012 7:45 am |
|
|
You didn't provide info on the GPRS module, but many GPRS modules support some form of Over-the-air programming (OTA). Though this is only useful for the GPRS' internal memory I know many modules that have spare memory and processing power available to the user much more powerful than the external PIC.
You could consider getting rid of the PIC and move the software into the GPRS module... Less components, smaller, cheaper and OTA for free. |
|
|
overmindx
Joined: 06 Oct 2008
Posts: 43
|
|
| Posted: Mon Feb 06, 2012 8:23 pm |
|
|
hello.. thanks for all your replies.
| Quote: |
You could consider getting rid of the PIC and move the software into the GPRS module
|
I can't get rid of the PIC because it is the one acquiring data from the sensors attached to the datalogger and it sends the data using gsm/gprs to our server.
| Quote: |
Possible yes. Most people doing similar things are preferring a storage device, e.g. serial flash to allow complete download and verification of the firmware image before programming it. |
In my datalogger, I have a SPI flash memory chip. Is it possible to store the firmware there and when I do a software reset, the bootloader will get the firmware from the flash chip via SPI and program the MCU? Is this possible? Please help. Thanks.
-- overmindx -- |
|
|
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Tue Feb 07, 2012 12:32 am |
|
|
| Quote: | | Is it possible to store the firmware there and when I do a software reset, the bootloader will get the firmware from the flash chip via SPI and program the MCU? Is this possible? |
You need to implement SPI flash access in the bootloader. Assuming the firmware image will be stored in a binary format, it's less effort than the usual hex file parser. |
|
|
asmallri
Joined: 12 Aug 2004
Posts: 1634
Location: Perth, Australia
|
|
| Posted: Tue Feb 07, 2012 1:38 am |
|
|
| FvM wrote: | | Quote: | | Is it possible to store the firmware there and when I do a software reset, the bootloader will get the firmware from the flash chip via SPI and program the MCU? Is this possible? |
You need to implement SPI flash access in the bootloader. Assuming the firmware image will be stored in a binary format, it's less effort than the usual hex file parser. |
Complexity is in the eye of the beholder. In this method the hex file must first be parsed to put it in the appropriate location of the external flash. In this case an application level program must put the code into the external flash or the bootloader must function as a standard bootloader to load the external flash and then as an SPI bootloader to bootloader the PIC's program memory. In both cases this is more complex not simpler than a standard bootloader. Special treatment is required to deal with the config bit and EEPROM records although the config bits is not really an issue because they are typically ignore by the bootloader to prevent bricking the hardware. If the external FLASH is smaller than the PIC program memory space there you need to define some form of memory management solution for mapping into the external flash. Bootloading the PIC from the external flash may fail due to an external event, such as power failure, so the bootloader would need to implement an integrity checking mechanism at each reset / power cycle of the PIC.
If the gprs modems basically establish a point to point serial connection between the programmer application and the PIC then a standard serial bootloader will work fine provided the bootloader will automatically enter bootload mode if the PIC does not contain a successfully bootloaded image.
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
|
| Posted: Tue Feb 07, 2012 1:42 am |
|
|
| Quote: | | Is it possible to store the firmware there and when I do a software reset, the bootloader will get the firmware from the flash chip via SPI and program the MCU? Is this possible? |
Yes, this is possible and not very difficult. Have a look at the many existing serial port bootloaders and modify these to read data from SPI.
Many of the serial port bootloaders expect a hex-coded file as input but for you this is unneeded overhead, you can save (and read) binary data to the external memory. Just add a checksum code somewhere to ensure the data is valid.
One of the more difficult parts will be to setup the SPI Flash memory at startup, but this is working code you already have for normal operation so should just be a copy/paste action.
It would be easiest when the firmware is always located at a hardcoded memory location in the Flash memory because then your bootloader doesn't have to know about the file system and can be kept smaller == easier == less bugs.
You are already using the external SPI Flash memory for your data logging application. Is this using a real file system like FAT32, or are you using some address based system? |
|
|
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Tue Feb 07, 2012 4:08 am |
|
|
| Quote: | | Complexity is in the eye of the beholder... |
Many points mentioned in the post are not specific to a SPI bootloader, e.g. the behaviour in case of image download failure respectively image integrity check, or the question how to handle configuration bits. Regarding the latter question, it's clear in my opinion, that a failsafe bootloader must never touch the bootloader area, reset vector or configuration bits. The point of decoding a binary image holds, in fact it has to be done at least once by a hex bootloader.
Generally, there are various pros and cons and the different solutions have been sketched sufficiently that everyone can decide on its own, I think.
The GSM/GPRS point shows as follows in my opinion:
You can easily configure a GSM modem to make a circuit switched connection to the device (accept calls automatically etc.) Fixing the initial baudrate is a minor solveable problem in this context. Unfortunately, there's zero application security without additional means.
GPRS isn't a serial peer-to-peer connection by design, it's a TCP/IP network. Using an intelligent modem with integrated TCP/IP stack, you can setup a TFTP or simple serial server by the bootloader and allow your remote update application to connect to it. But obviously some configuration (provider selection, security) is required. So it's not deceptive to think about doing all configurable activies at the main application level.
It's also true, that some GPRS modem offer additional intelligence, up to running java applications. But the solution involves a more complex product design, more components to be initially programmed and additional failure scenarios as well. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
