My team-member is moving to a different city. So how can he upload his codes, when the board is with me, many kilometers away from him. Is there an option of burning the codes in a wireless-mode? If yes, what will be the hardware/software requirements. (this is only for Atmega32 uC)


closed as unclear what you're asking by PeterJ, Hans, Bimpelrekkie, Voltage Spike, Dmitry Grigoryev Aug 31 '17 at 8:43

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    \$\begingroup\$ why not get him to send them to your computer (eg, by email) and use that to burn the codes. \$\endgroup\$ – Jasen Aug 27 '17 at 9:14
  • \$\begingroup\$ Why not give him the board instead? Or get a 2nd board and make him send you the program, so you can program&test it? Or perhaps.. this is the point where you find out developing hardware & firmware on remote locations is a nightmare unless you take the necessary precautions and spend the extra effort. \$\endgroup\$ – Hans Aug 27 '17 at 9:32
  • 3
    \$\begingroup\$ Store the project files on github (free/no-cost if you don't mind the files being publicly visible). If the project has source code you'll need an SCM system like git or subversion anyway, to avoid losing the precious source code when it's crunch time. This keeps historical backups of your project, and lets all team members read and write the same project files, regardless of distance. \$\endgroup\$ – MarkU Aug 27 '17 at 10:26
  • \$\begingroup\$ flash not burn wirelessly: forget about that. Although it is possible (a smartphone can do it) it is an extremely complex process. In a smartphone everything needed is already there anyway. Not so on a uC board. Also a smartphone uses a cellular network, for which a subscription fee is needed. Are you willing to go that far (money wise) if the same can be achieved in the ways as described above ? The github thingy is exactly made for this purpose (teamwork, sharing code) so why not use that. \$\endgroup\$ – Bimpelrekkie Aug 27 '17 at 10:36
  • \$\begingroup\$ We're just beta testing this feature, and the amount of R&D it has required so far is such that I wouldn't bet a lot on you getting any sort of answer here. We don't work for free, sadly. You could try hiring someone who can do this. Expect a lot of figures on the bill. \$\endgroup\$ – Tibo Aug 27 '17 at 18:19

You need to develop a bootloader (or find one that suits you). It is an application that occupies part of MCU flash memory and can write the other part with main application and start your main application. A bootloader can use any variety of communications methods. In your case it could be Bluetooth, GSM, ZigBee, WLAN or a custom protocol with an 868MHz radio.

  • \$\begingroup\$ Can you please suggest us the basic framework, or rather the algorithm/flowchart, of how to implement it? \$\endgroup\$ – AJ1993 Aug 27 '17 at 13:43
  • \$\begingroup\$ You did not specify the MCU. If it is an AVR you can look at the stock AVR109 bootloader. It has serial connectivity. You could use it with a Bluetooth to serial module. Software is widely available (avrdude). \$\endgroup\$ – filo Aug 27 '17 at 13:51
  • \$\begingroup\$ Apologies for not mentioning my uC. I am using Atmega32 \$\endgroup\$ – AJ1993 Aug 27 '17 at 13:55
  • \$\begingroup\$ Is there any way we could use it with GSM? If yes, what will be the hardware/software required? If possible, can you please give us any links to any websites/resources which will be useful? Thanks. \$\endgroup\$ – AJ1993 Aug 27 '17 at 13:59
  • \$\begingroup\$ Look at companies that make cellular modules (Simcom, U-Blox, Quectel, Telit...), read the AT command manual and see how to download file over HTTP. There is a long way ahead of you. \$\endgroup\$ – filo Aug 27 '17 at 14:02

No, it's generally not possible to update device firmware over wireless, and here's why:

From a security perspective, any interface that allows loading device firmware can be a potential "attack surface". If it is possible to load firmware into the device through some anonymous wireless interface, bad guys will discover this attack surface and will try to exploit the device. Even if it seems like your device doesn't do much, if it has an unsecured internet connection and allows arbitrary code to be inserted by anyone, it's a very tasty target. Many "internet of things" devices, including IP cameras, get hacked because of carelessness.

If the problem was really how to allow firmware to be updated over-the-air, it's possible, but to do it right requires a lot more effort and a much larger team. You'd need a crypto library (don't try to invent your own!) and some certificates and a way to validate that the firmware being received is from a trusted source.

If the problem you're trying to solve is how to do embedded systems (hardware+software) development with a small team, with remote access, there's a better way. Create an account on github.com; this is free/no-cost if you don't mind the files being publicly visible. For a university capstone project that's what I'd do. If this is a professional project under NDA, you can get a private repository for a nominal fee.

Since the project has source code, you'll need an SCM (Software Configuration Management) system like git or subversion anyway, to avoid losing the precious source code when it's crunch time. Either git or subversion is a fine choice; there are lots of SCM systems and they all work well enough. An SCM system keeps historical backups of your project, and lets all team members read and write the same project files, regardless of distance.

You will need a second set of hardware; both the target ATmega32 uC board, and its device programmer board. When your remote team member commits new changes to the github repository, you can grab the latest update through github, and then use your local device programmer to load the firmware onto your remote board.

This also gives you a little bit of "crunch time" protection, in case one of the boards gets smoked you can swap boards.


Not the answer you're looking for? Browse other questions tagged or ask your own question.