BitCloud ver 3.0.0 OTAU

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

Hi guys,

I have created some network with ATmega256RFR2 (based on WSNDemo project with a lot of changes). It has coordinator and 10 other devices. 10 is both routers and end devices: each device sends synchronization data to coordinator. Coordinator builds array of structs to know which devices in network. If coordinator does not receive data, it is mean that device left network. ENC28J60 is connected to coordinator MCU and serves as a bridge between LAN (UDP used) and ZigBee.

And now I want to add OTAU for each device in ZigBee network. I wanna start from coordinator. As I understand it: the new firmware is received via UDP, verifies integrity, written in AT25DF041A, after that bootloader is changed MCU firmware. I'm new to this so I have some questions.
1. For this goal I need to write own procedure for received data and write to Flash memory. I can use standart code in boot section from WSNDemo. Is it right?
2. I hope that I can use OFD. This saves me from having to write own code for communication with SPI memory. Is it right?
3. In AVR2052 pages 40-41:
External Flash pins ATmega256RFR2 pins
CS PE3 (pin49)
SO PE0 (pin46)
SI PE1 (pin47)
SCK PE2 (pin48)
As far as I understood it is UART0 in MSPI mode.
But in OFD_Open():

#if defined(ATMEGA1281) || defined(ATMEGA128RFA1) || defined(ATMEGA256RFR2) || defined(ATMEGA2564RFR2)
  spiDesc.tty       = SPI_CHANNEL_0;
  spiDesc.baudRate  = SPI_CLOCK_RATE_2000;
#elif  defined(ATXMEGA256A3) || defined(ATXMEGA256D3)
  spiDesc.tty       = SPI_CHANNEL_D;
  spiDesc.baudRate  = SPI_CLOCK_RATE_8000;
#endif
  spiDesc.clockMode = SPI_CLOCK_MODE3;
  spiDesc.dataOrder = SPI_DATA_MSB_FIRST;
  spiDesc.callback  = NULL;

  if (-1 == HAL_OpenSpi(&spiDesc))
  {
    sysAssert(ofdCallback, OFD_NULLCALLBACK0);
    ofdCallback(OFD_SERIAL_INTERFACE_BUSY);
  }

It is SPI. Do I need to change it to UART0 in SPI mode?
4. AVR2054 is says than JTAGEN fuse bit must be enable. Why? What do if I want to use this pins as simple input/output?

Thanks in advance for your help!

Last Edited: Fri. Oct 16, 2015 - 12:50 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

First of all, prepare to look in the code a lot. OTA upgrade is a very complicated procedure.

1. Yes, you can use standard bootloader, but it is not a part of WSNDemo. It is a standalone application.
2. OFD has very specific interfaces. I'm not 100% sure it would be possible to use as is.
3. HAL_OpenSpi() with channel 0 opens USART in SPI mode.
4. I don't think it is necessary to enable JTAG for any of this.

Also note that you will need to write information about the new image into first few bytes of the EEPROM, so that bootloader could pick it up.

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 decided to write all OTA procedures from zero. This will easier and faster for me. I created working bootloader as a standalone application.

How can I combine both output files? I would like to have one elf-file which including main application and bootloader together. I tried to find a description elf-file format. Description header file that's all I could find.

How to make that WSNDemo did eep-file too?

Thanks for your help!

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

I don't think there is a way to do that with elf files directly. Format of the elf file is very complicated.

Use avr-objcopy to convert your files to binary or Intel hex files and combine them.

If I remember correctly EEPROM was transferred as a regular image, but offset is outside of the normal flash range.

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

Yes, alexru, when I develop devices, hex-file is more then enough. But when I finish, other guys will programming microcontrollers in manufacturing. We simply give them BOM, gerber files and elf-files. Elf-file is good way programming one-button mouse. I know that a programming error is minimized in this case. Of course I can give two hex files for flash and eeprom and write instruction how set fuses and lock bits manually. The probability of error in this case increases.

I have opened elf-file like binary file, converted it to ASCII string. I saw that there are a lot of different information which not need for programming controller directly.

I see two ways:
- combine output files from two projects together;
- added bootloader to main project and receive one output file.
The second seems to me more difficult.

As far as I understand in first approximation: data from bootloader hex file will added in end of flash in elf file. Checksum will changed. Program header will be changed too. Our guys can write PC software which combine elf-file from main project and hex file from bootloader project. But I cannot find full description of elf file format!!! Nothing can be done without understanding design of elf file. Where can I find this information? Or can you suggest another way?

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

Sashal wrote:
Elf-file is good way programming one-button mouse.
Ok, I see your point.

Try playing with objcopy and see if it can combine files.

Sashal wrote:
I have opened elf-file like binary file, converted it to ASCII string. I saw that there are a lot of different information which not need for programming controller directly.
Generic ELF files have very complicated structure. ELF files that contain simple non-relocatable code are better, but still they are not designed for manual parsing.

Sashal wrote:
Our guys can write PC software which combine elf-file from main project and hex file from bootloader project.
If you have programming resources, then use libelf to parse and generate the file.

If you want the spec, then google "Portable Formats Specification, Version 1.1". This will give you a generic description. Then you will need to find description of AVR-specific parts.

The better approach would be to create a tool for programming that uses atprogram (command line utility from Atmel Studio) as a backend. You can pass Flash image, EEPROM image and fuses as separate parameters.

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!

Atprogram is simply cool!!! It solved all our problem. It's a pity that I have not heard about this utility before.

Is it possible that coordinator sends data for all devices (R + ED) in network? It is good way to send new firmware for devices at the same time.

Thank you

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

Sashal wrote:
Is it possible that coordinator sends data for all devices (R + ED) in network?
Yes, by using broadcast messages.

Sashal wrote:
It is good way to send new firmware for devices at the same time.
No, it is not. Without confirmation you will have too many broken images. It is possible to request missing parts later, of course. But it is much better to have unicast messages and controlled request rate to balance network traffic.

Also broadcast works, even in theory, if you have only one type of device in the network.

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

Ok, I see. Thank you for fast reply.

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

Hi!

I have some interesting effect and I cannot explain it. Absolutely no idea. Perhaps you will find explanation.

I am doing OTAU for coordinator on atmega256rfr2 xplained pro kit + two my boards with external flash and ethernet controller. I am programming main firmware (flash + eeprom) and then programming bootloader firmware (flash only from hex file, without erasing chip before programming). Fuses has attached. No lock bits.

Main program receives new firmware, saves to external flash and resets. Tried:

HAL_StopWdt();
HAL_StartWdt(WDT_INTERVAL_16);
while (1) { }

and

HAL_WarmReset();

with the same results. Bootloader starts, sees flag for new update and starts update flash. After that MCU is reset. If I turn on led at the beginning bootloader, it is look like fast blinking. Simply infinite loop: start, reset during erase and write flash. Unfortunately I cannot debug in this case. Reset button does not have any effect.
But if I disconnect and reconnect the power cord (off and on 3.3V), all is ok. Bootloader writes the new firmware and jumps to 0 address. If main program receives new firmware and after that I program bootloader via programmer, all ok too.

Generally no idea why this happens. All forum members help please!!!

Attachment(s): 

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

Once enabled, WDT stays enabled, even after reset. This is a safety feature.

The first thing your bootloader must do is disable WDT.

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

Ok, I understood. It is working now. Thank you.

What is the maximum packet size which I can send via air? Where I can find this information?

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

For plain stack and unsecured messages it is about 90 bytes or so.

I think Peer2Peer application calculated maximum message size based on the definitions from the stack.

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 am transmitting firmware from C to ED successfully. Then bootloader updates flash and eeprom. Everything seems to be fine. But it is very very slowly. 526 pages has been transmitted within about 2 hours. I have divided page to 8 packets 32 bytes each. Ie 526*8=4208 packets was sent. C is waited reply for each data packet. Endpoint is the same that for main application. Is there a way to increase speed (reduce time)?

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

Update rate for the ED is limited by CS_INDIRECT_POLL_RATE. You may try to decrease this value, may be only during the update.

But in general, OTA update for EDs is slow, and there is not much you can do about that.

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

alexru wrote:
Update rate for the ED is limited by CS_INDIRECT_POLL_RATE. You may try to decrease this value, may be only during the update.

It really helped. I reduced this value to 100 ms at the beginning of the update.
alexru wrote:
But in general, OTA update for EDs is slow, and there is not much you can do about that.

Early, flash + eeprom have been updated about 135-140 minutes. Now it is 16-17 minutes! Just cool!
There is no dispute that it is a long process. But not few hours... :D

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

Quote:

Yes, alexru, when I develop devices, hex-file is more then enough. But when I finish, other guys will programming microcontrollers in manufacturing. We simply give them BOM, gerber files and elf-files. Elf-file is good way programming one-button mouse. I know that a programming error is minimized in this case. Of course I can give two hex files for flash and eeprom and write instruction how set fuses and lock bits manually. The probability of error in this case increases.

not sure if you've resolved this but the way to approach it is this:

1) build the bootloader as one app
2) build the application as another
3) when you finally have two .hex (not .elf) then combine them. Do that either using srec_cat or just edit the files together and remove the termination record from the end of the first
4) Now in Studio use the programming dialog to also set other things like fuses and so on.
5) for the flash image tell it to use the combined file in (3)
6) now get it to write a "production elf file" that combines everything
7) give that to manufacturing.

Morten (AS6-Atmel) has said that in a future release they'll even add the possibility to introduce TWO .hex files into the programming dialog so it can do the joining option for you. But for now do it manually.

For (6) see this page:

http://www.atmel.com/webdoc/atme...

In the middle of:

you can see the "Save to ELF production file" which is where Atmel take all the ingredients and build a single output ELF for you.

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

thank you clawson. My way is creating own gui application (based atprogram and avr-objcopy utilities). boot.hex and main.elf (flash+epprom+lock+fusus) files in application folder:
1. Start program, initialize random number generator like this http://www.cplusplus.com/reference/cstdlib/srand/
2. Select device type (coordinator, router or end device) using radiobuttons. Own firmware is for each type device.
3. Push PROGRAM button, starting programming
3.1. Create eeprom.hex from main.elf using avr-objcopy (once if eeprom.hex is absent).
3.2. Generate random address (8 bytes) and write is to last 8 bytes EEPROM in eeprom.hex. Change checksum. Ie personal address for each board.
3.1. Erase MCU
3.2. Verify signature.
3.3. Program bootloader in flash.
3.4. Verify bootloader in flash.
3.5. Programming flash from main.elf.
3.6. Veryfy it.
3.7. Programming eeprom from eeprom.hex
3.8. Veryfy it.
3.9. Program fuses from main.elf.
3.10. Veryfy it.
3.11. Program lock bits from main.elf.
3.12. Veryfy it.
4. Show message that programming has been finished.

Now we discuss that is better: random number generator or increment the previous address. Theoretically, it will be on several computers. And random generator looks preferable.

We are open to any suggestions.