PDA

View Full Version : Upload the Script wirelessly


vivekgang
09-07-2010, 08:55 AM
Hello Every One....

I have Successfully Develope a SNAP sysem which can have two Modes
-Configuration Mode.
-Data Mode.

we can Easily switch between the Modes with the single command

In this system there is no need the Portal Software to Configuration
through the Hyperterm we can Configure the All the SERIAL and NETWORK Parameters of the Local node as well as other Nodes wirelessly in the range of 100 meter.
In Data Mode through the UART we can send the data and recieve wirelessly On the UART at another Node.

But I am Thinking to Upload the Script wirelessly through One Node to another Node ,Is it possible.
If any Body have any Idea then please give me Suggetion for this..

Thank You.

kactamus
12-18-2010, 09:57 PM
I would like to know how you updated the synapse firmware remotely?

vivekgang
12-23-2010, 11:30 PM
Hello Dear,

I am also looking for update the f/w remotely...
If you have any option plz tell me...


Thanks.

kbanks
01-03-2011, 06:06 PM
No SNAP Nodes to date support OTA Firmware Update.

This is because they lack sufficient FLASH memory to support TWO copies of SNAP (the one being talked to, and the "next" copy being sent OTA).

Options for now:

1) "Pair up" the SNAP nodes such that one is only used to wirelessly update the other one (effectively use one as a wireless UART, since the SNAP Bootloader DOES support firmware update via serial).

We have used this trick here in the lab, but I am unaware of any field deployments.

Note that this technique requires the "uploader" node to be able to reboot the primary node (some GPIO pin on the first node connected to the RESET* pin of the primary node). This is needed because a hardware reset (or a power cycle) is required to initiate the serial upload process.

2) Add additional external memory (serial EEPROM for example), AND use a custom bootrom. Contact our Custom Solutions group for either a "hardware and software" quote (to design your board AND create a custom bootloader for it) or a "software only" quote for just the custom bootloader. (The standard SNAP Bootloader only supports serial reprogramming of INTERNAL FLASH).

nanoeng
01-27-2011, 04:15 PM
No SNAP Nodes to date support OTA Firmware Update.

This is because they lack sufficient FLASH memory to support TWO copies of SNAP (the one being talked to, and the "next" copy being sent OTA).

Options for now:

1) "Pair up" the SNAP nodes such that one is only used to wirelessly update the other one (effectively use one as a wireless UART, since the SNAP Bootloader DOES support firmware update via serial).

We have used this trick here in the lab, but I am unaware of any field deployments.

Note that this technique requires the "uploader" node to be able to reboot the primary node (some GPIO pin on the first node connected to the RESET* pin of the primary node). This is needed because a hardware reset (or a power cycle) is required to initiate the serial upload process.

2) Add additional external memory (serial EEPROM for example), AND use a custom bootrom. Contact our Custom Solutions group for either a "hardware and software" quote (to design your board AND create a custom bootloader for it) or a "software only" quote for just the custom bootloader. (The standard SNAP Bootloader only supports serial reprogramming of INTERNAL FLASH).
Hi KBanks,

Do you guys have any plans for changing this system constraint any time in the near future?

Ric

kbanks
01-27-2011, 04:32 PM
Do you guys have any plans for changing this system constraint any time in the near future?

Since it is a hardware constraint, it cannot be changed on the existing modules. The available FLASH memory is internal to the chip, and so is fixed.

As new modules come out in the future, some of them may have sufficient internal hardware resources to support such a feature.

If there were enough customer interest, we might come out with a higher priced version(s) of an existing module(s) that contain external memory and a new bootloader to support this feature. To date, we have not seen enough interest (many are interested in remote firmware update, but nobody wants to pay for it).