XMEGA supports over the air programming?

Go To Last Post
18 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I just want to know whether  XMEGA32a4 supports  Over the AIR programming or not. 

MQX(K12) controller suports the OTA programming. just wanted to know weather XMEGA support it or not

Last Edited: Mon. Aug 31, 2015 - 10:27 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Surely, you are joking!

 

First of all, in my mind, "support" means that there has to be an on-board radio chip. No Xmega has that.

 

Second, for over-the air, you need enough ram to store the entire program image BEFORE it gets burned into FLASH. What happens in that RF link is broken part way though? There has to be a way to go back to the previous version. One of VERY few ways to do that is to NOT burn until the complete program is on-board. To do that, you need to be able to store it all. OR, you have double the amount of needed flash, and simply jump to the appropriate one, once complete. AFIK, no 8/16 bit MCU has either of these features.

 

Looking at the Freescale site, I get the strong impression that MQX is an RTOS, not a microcontroller. So, maybe you need to reconsider your question?

 

Further searching shows that their Over The Air programming uses the "two images in flash" method on Kinetis Cortex M8 MCUs. Those are 32 bit ARM chips. Sorry, not in the 8/16 bit world.

 

Jim

 

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How about custom bootloader that can handle transmission and programming even without valid application? :) Even if something went wrong you are at point where you can reflash everything :)

I'm just before the moment where I have to add such 'thing' to my xmega project. Bootloader will have to 'understand' addressing and framing to receive packets of new firmware :) It shouldnt of course mess up anything with other devices on the bus :) Looks like something that can be done ;-)

Last Edited: Mon. Aug 31, 2015 - 06:39 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

DemmoC wrote:

How about custom bootloader that can handle transmission and programming even without valid application? :) Even if something went wrong you are at point where you can reflash everything :)

I'm just before the moment where I have to add such 'thing' to my xmega project. Bootloader will have to 'understand' addressing and framing to receive packets of new firmware :) It shouldnt of course mess up anything with other devices on the bus :) Looks like something that can be done ;-)

 

bad idea.

This would mean your bootloader is now as smart as the app.

Just validate the FW image before flashing it.

If you want to be extremely paranoid keep two copies of the FW in memory, the last known good and the current one.

 

Then all you have to do is figure out all the impossible scenarios when the new FW is corrupt, simple :P

Keith Vasilakes

Firmware engineer

Minnesota

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think you'd have to have some external memory, maybe one of those spi flash chips. The main app receives the new image from the RF system and stores it in the external memory. When it's all received and verified, maybe CRC checked, it then reboots the chip into the bootloader that finds the new image on the external store and flashes the processor from that. I've used NRF modules for all sorts of things, but I haven't tried reflashing the program with them. I haven't even tried making a bootloader.

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

The original reference appears to be about an RTOS built around Freescale Cortex M8 mcus. These M8s appear to function as though there are two flash regions. I would guess that you can program the reset vector to jump to the desired half of the flash. This allows you to (try) loading a program into one half, and if not successful, then leave the reset jump pointing to the OTHER half. At the very end, when the bootloader has established the validity of the newly burned image, it (the bootloader) can change the reset jump destination. 

 

This would seem to be a relatively clean way of trying over-the-air programming. I would be more concerned with a bootloader that implements deep error detection and is able to request re-send of any particular "packet" from the sender. 

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Of course full image checking and flashing is better than chopping it to packets and trying to figure out if everything is ok when image 'should be' complete. I didn't mean that after flashing bootloader will ask to resend anything. Protocol has implemented CRC checking so when something is wrong with frame it can ask for new one. If frame is OK it is flashed to given memory address. After all there should be another test to check image. You can ask bootloader if everything is OK or you are still talking to bootloader and repeat flashing. It's all about "what happens when you fail?" If it's not critical in any way, why should I bother? In any troubles I can always lift my butt and program it in classic way ;)

 

EDIT:

Just thinking - what's the difference between that approach and any option where you upload firmware word by word? You can always have corrupted firmware and this is why Verify option exists.

Last Edited: Tue. Sep 1, 2015 - 04:05 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

MADHUARA V S wrote:
I just want to know whether  XMEGA32a4 supports  Over the AIR programming or not.
fyi, XMEGA256A3 and XMEGA256D3 are in AVR2054 Serial Bootloader for some Atmel REB (Radio Evaluation Board ?) and STK600 plus RZ600.


Atmel AVR2054: Serial Bootloader User Guide

http://www.atmel.com/images/atmel-8390-wireless-avr2054-serial-bootloader-user-guide_application-note.pdf

...

The OTAU bootloader is able to load an application image, which has been received by the application over the air and saved in an external memory device, and program it into the internal flash memory ...

Atmel Corporation

Atmel AVR2054 Serial and OTA Bootloader

https://gallery.atmel.com/Products/Details/992efa59-3d2f-44b8-aa4d-ea7630026ed5

"Dare to be naïve." - Buckminster Fuller

Last Edited: Tue. Sep 1, 2015 - 06:47 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok thanks, I studied the boot loader concept and self programming concept, Not clearlly understood but still i give it  a try by moving forward.

Loaded the xboot.hex file to xmega32a4u and boot file starts from the location 0x8000

None of the API are working.
Im totally lost
Added Xbootapi.c and .h to my application code and called some of the API. None of them working........

Im totally lost ...crying

Last Edited: Thu. Oct 1, 2015 - 11:38 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Perhaps say some more about what you want to achieve? What makes you think "xboot" is the solution? How are you planning to use it?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm just trying the self programming in xmega32a4u.

I just want my firmware to update itself.

Am i going i wrong direction surprise

 

 

(Please give me proper suggestion and instruction )

Last Edited: Thu. Oct 1, 2015 - 12:19 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Um. Dare I say, "Start with blinking an led"?

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Though not yet an RTOS, mbed also has that capability for some Freescale ARM Cortex and, if I read it correctly, some NXP ARM Cortex.

ARM mbed

Cookbook

Custom Peripheral Drivers

https://developer.mbed.org/cookbook/Homepage#custom-peripheral-drivers

(search for "In-Application Programming")

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"wrong" is relative.

An alternate direction is to have an auxiliary MCU or MPU that runs a loader to communicate with the bootloader on the XMEGA32A4U.

I cannot recall if there's a port of Optiboot to XMEGA; there are some Arduino bootloader ports to XMEGA.

Might consider moving from an XMEGA32A4U to an XMEGA32E5 though the A4U has some advantages (more pins, faster ADC, USB device, etc.).

If you want to use Bluetooth 2, Adafruit rolled their own loader software into a Bluetooth-capable MCU that communicates with an Arduino bootloader (see correction).

Adafruit has distributors in India.

Correction : Bluefruit EZ-Link is a relay for the signals to and from a loader on a PC or Mac.


GitHub

XMegaForArduino/arduino

arduino/bootloaders at master

https://github.com/XMegaForArduino/arduino/tree/master/bootloaders

Adafruit Logo

Adafruit Learning System

Introducing Bluefruit EZ-Link Breakout

https://learn.adafruit.com/introducing-bluefruit-ez-link?view=all

Adafruit Logo

Adafruit Industries, Unique & fun DIY electronics and kits

Hacker Spaces/Distributors Map

https://www.adafruit.com/distributors

Edit : "Correction - ..."

"Dare to be naïve." - Buckminster Fuller

Last Edited: Tue. Oct 6, 2015 - 06:17 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

to be more clear,

Im using Xmega32a4u controller. There is an Fibocom G510 GPRS module, 

I will be recieving my new code over gprs and my controller should update the firmware by new one which i received through GPRS.

How can i achieve this?

 

One question? is it possible to access flash region from Application code?

Im able to access flash(read/write) throgh boot loader.

 

Last Edited: Mon. Oct 5, 2015 - 06:57 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

One question? is it possible to access flash region from Application code?

Im able to access flash(read/write) throgh boot loader.

A program in flash can read its own flash (use pgm_read_byte() or similar mechanisms) but the only way an AVR (well Xmega anyway) can write to its own flash is by executing code in the bootloader section as that's the only place the SPM opcode works.

I will be recieving my new code over gprs and my controller should update the firmware by new one which i received through GPRS.

Then I'm not entirely understanding why you feel the need to use the API that Xboot provides. That is code that resides in the bootloader that can be called from application code to do stuff like writing flash while the app is running - why do you need to do that? Are you planning to receive the new firmware image while the application, not the bootloader is running then?

Last Edited: Mon. Oct 5, 2015 - 08:41 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

thanks clawson,

I understood a little bit. I was trying to access flash from my application code.

I understood that  i can only access flash from my boot section smiley

 

Are you planning to receive the new firmware image while the application, not the bootloader is running then?

So what you are telling is that " in boot section i need to receive the new firmware and then i can erase the application section and i can update the new image" 

am i correct ?

Last Edited: Tue. Oct 6, 2015 - 06:37 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

MADHUARA V S wrote:
I will be recieving my new code over gprs and my controller should update the firmware by new one which i received through GPRS.

How can i achieve this?

  • GPRS stack in AVR application space, SPI-attached memory (flash, MRAM, SRAM, etc), bootloader reads external memory (one way is by AVR2054).
  • GPRS stack on Linux, loader on Linux, loader and AVR bootloader communicate via serial or USB.

Moving a communication stack off an AVR into <what-ever> might be the way to go (think "threat model", TLS, VPN, etc.); the context for that statement is USA 2G and 3G is really not secure.


Arduino

GSM

https://www.arduino.cc/en/Reference/GSM

Seeed Studio

Wiki

GPRS Shield V2.0

http://www.seeedstudio.com/wiki/GPRS_Shield_V2.0

ChiliPeppr

Hardware Fiddle

http://chilipeppr.com/

http://chilipeppr.com/downloads/v1.86/README.md 

GitHub

arduino/serial-port-json-server

https://github.com/arduino/serial-port-json-server

A serial port JSON websocket server for Windows, Mac, Linux to communicate with Arduino boards.

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Tue. Oct 6, 2015 - 07:18 AM