[Bitcloud] How do I use OTAU's in the zigbee network, but use my own bootloader on the coordinator

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

Hi team!

 

I am currently using bitcloud 3.2.0 and have I am using the Atmega2564RFR2 on all my devices. My main board that I will use as a coordinator I am using the rf chip as a zigbee supporting chip to the main atmega1284P. Currently I can do OTA's to my 1284P and have created another bootloader with my own protocol to program the rf chip and it appears all my bootloaders are programming my chips correctly (Verified with ICE flash read and general application operation).

 

My issue is that while reading the zigbee configuration.h file and looking at the hex file, I have 2 options. I can disable the dependecy on the bootloader by leaving the definition "#define PDS_NO_BOOTLOADER_SUPPORT" uncommented, but it adds a small application to the bootloader section of the hex file. Or I can comment the line out and it creates a dependency on the bootloader, typically the atmel bootloader from the application note (if I read one of the previous posts correctly).

 

Am I correct in what I have mentioned above? Or have I somehow misread the comments?

 

Ideally I would like to use my own bootloader on the coordinator chip, use it as the OTA server and pass the flash file to it so it can do the OTA to the routers and/or end devices that use the default bootloader. Can this be done without going too deep into the stack?

 

Looking forward to some advice,

Ryan :)

Last Edited: Thu. Oct 15, 2015 - 09:54 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

You are correct. In AVR, only code executing from the bootloader section can write to flash. So you will need this section (it can be a part of your bootloader, if you want to). You will also need it for PDS, even you you don't do any OTA upgrades. PDS stores its database in the flash, so it calls those functions from the bootloader section when it needs to write the sector.

 

I'm not entirely clear on where you want to store the image and how you want to distribute it to routers. Can you clarify this.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

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

Thanks Alex! That actually cleared up a bit in terms of why it was there/that section was required.

 

I ideally would've liked my 1284P chip to do an update on the 2564rfr2 via my own bootloader. But still be able to use this chip and the in-built zigbee stack on it as the coordinator to do OTA's to it's slave routers and end points.

 

I think I have realised (while not the best solution) I can actually write my bootloader and set the boot fuses on the 2564rf from 0xF800, leaving the application in the bootloader section that occupies the range 0xF000-0xF3200. This will allow for small upgrades to small application in the future if it was expanded.

 

Does this sound like it could work alright?

 

I hope this further clarifies your question.

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

ryanafleming wrote:
I ideally would've liked my 1284P chip to do an update on the 2564rfr2 via my own bootloader. But still be able to use this chip and the in-built zigbee stack on it as the coordinator to do OTA's to it's slave routers and end points.
That's reasonably easy to do. Just write your own bootloader, but take those couple functions that are needed for the main firmware. There is also a small section at the end of the bootloader that contains pointers to those functions. All of this is resolved through a linker script. It is actually not that hard. you can also start form  BitCloud bootloader and strip it down, there are huge chunks of code that can be eliminated easily. And then build your own on top of that.

 

ryanafleming wrote:
I think I have realised (while not the best solution) I can actually write my bootloader and set the boot fuses on the 2564rf from 0xF800, leaving the application in the bootloader section that occupies the range 0xF000-0xF3200. This will allow for small upgrades to small application in the future if it was expanded.
I'm not sure I get what you are trying to do. What small application?

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

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

hi alexru,

I seen many post where u commented/solved problem related to OTAU.

 

Im new to programming world, forgive me if im wrong.

 

Actually i want to use OTAU concept in XMEGA controller

what is the requirement i need/ i should consider?.

 

suppose im using XMEGA32a4u controller(which has fibocom G510 GPRS module) , can i upload the new image through GPRS? 

 

 

 

Last Edited: Mon. Sep 7, 2015 - 05:49 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Hi Madhuara,

 

This post was actually originally relating to the atmel zigbee stack called Bitcloud specifically used for the atmega rf chips like the 256rfr2, 2564rfr2 etc.

 

What you're asking can be done quite easily. Many posts exist on avrfreaks that suggest ways you can do OTAU's through bootloaders. I would recommend starting here with this faq. Or simply find an existing bootloader...

 

It would be best to start with writing a small application serially before going through the modem.

 

Good luck!

Last Edited: Tue. Sep 8, 2015 - 07:28 AM