Reward: $500 for a working bootloader for ATmega256RFR2

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

I need a working bootloader for OTAU for the ATmega256RFR2 in the next couple of days. I don't have the skill or the time to acquire it.

 

Here's what I need specifically:

 

A hex file containing the bootloader and a program that slowly blinks an LED attached to PE3. I need to be able to load the hexfile via an AVRISP mkII. 

 

I should be able to use the Python script to send a binary file OTA to the boards. I should be able to do this countless times. I'll need you to tell me what code or include files are needed in my application to make my binary file compatible with your bootloader.

 

The first person to get me up and running successfully gets the $500. Don't tell me how to do it - just provide the hex file, instructions, and fuse settings. Send me an email to scott@solarroadways.com to start the process. I'll be hiring engineers soon and this would be a great way to show me what you've got (if you're interested of course).

 

Last Edited: Tue. Dec 13, 2016 - 03:34 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I will move this to Marketplace as you will get better responses there.

 

I ask that only those interested in actually working on this project respond to the email address provided. 

 

The OP has explained his problem in this thread:

 

https://community.atmel.com/foru...

Thanks,

JGM

 

EDIT: Spelling

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

Last Edited: Tue. Dec 13, 2016 - 03:34 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

solar roadways... didn't Dave Jones have "a few words" to say about them?

 

Ross McKenzie ValuSoft Melbourne Australia

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

Since the flash size is twice as big, the "address" of the bootloader section has moved to a higher address, so the jump to bootloader now has the wrong address in its code.

There may be other changes with dealing with a larger memory that may also need to be looked at.

 

Jim

 

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

Isn't that addressed in the fuse settings?

 

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

Did you recompile the program after changing the device#?  Or just load the existing hex file?

 

 

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

We load the existing hex file with an AVRISP mkII programmer. We then use the OTA Server to load our latest binary file to the board over the air.

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

You need to recompile for the larger flash mpu, the hex for the smaller part will not work as the bootloader is not located (loaded) into the correct part of the flash!

 

 

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

The hex was modified for the larger part. It was done by someone else and I don't have the source code.

 

This might help: after the hex file is loaded via the AVRISP, the LED on PE3 blinks slowly, indicating that the board is ready for a new program. I use the OTA Server to send the new binary file over the air to the board. The first time I do this, it works fine: the board resets and begins running the new program (let's call it Program A). It will not allow a second OTAU however: upon sending another binary file (Program B), the board locks up. When I power cycle it, it runs the previous program (Program A) and not the new one (Program B). This happens even if I'm sending the same binary file twice.

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

That sounds like I would expect it to work, since the bootloader is not running in the new bootloader section of memory, it can not write the new flash image.  With out the source, your looking at starting from scratch.  Sorry! q:-(

 

Jim

 

 

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

And that's what the $500 is for. Thanks anyway. 

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

If you don't already have someone in contact with you whose interested in writing your bootloader, then Chip45 may be able to do something for you. You'll notice that the device you're using isn't in the list of supported devices, however if you download the .zip containing the latest versions and take a look at chip45boot2_infosheet.pdf you'll see the following on the front page...

 

 

The only issue this would bring about for you is the protocol you're using to send your application image to your AVR may have to be altered...

 

 

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

When you try to run the bootloader the second time, does it appear to be working(i.e. slowly flashing the LED)?

When you say it locks up after trying the second bootload, does it go back to slow flashing after a power cycle?

 

To be honest, without source for the bootloader(and source for the PC end, do you have that?) you are pretty much screwed. If I had nothing else to do(and tha't about as far from reality as it gets right now), I'd offer to try and disassemble the hex and work out what's happening, but I'd want more than $500, even with the post-stupid-Brexit exchange rates.

 

 

Quebracho seems to be the hardest wood.

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

Not knowing which thread in which to post, I'll go here - the other one seems to be bogged down in working out what ISP & OTA mean. (Quite unbelievable really)

 

I wonder if the bootloader (or fuses perhaps) is becoming corrupted in some way. This experiment is not too technically difficult.

 

1. Using ISP, erase the device and program the bootloader stub.

2. Read back the entire contents of the flash and save to a file.

3. Note the fuse bytes.

4. OTA bootload your application code as you have been doing and run the application.

5. Connect ISP & read back the entire contents of the flash and save to a file.

6. Note the fuse bytes again.

7. OTA bootload your alternate application code as you have been doing and run the application. (You told us primary app runs and this is the fault)

8. Connect ISP & read back the entire contents of the flash and save to a file.

 

a. Using your favourite difference tool compare the hex files from step-2 and step-5, paying special attention to the bootload area at 0x1F000.

b. Also compare the fuse bytes for changes.

c. Using your favourite difference tool compare the hex files from step-5 and step-8, paying special attention to the application area at 0x0000.

 

 

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

I think N.Winterbottom is on the right track.

I'd still like to be sure of exactly what happens the second time you try to load the application, but maybe the bootloader is setting protection bits in the fuses(or do I mean lock bits?) after the first, successful, load, and then is unable to program/verify the blocks the second time around and crashes/hangs. WHen you reprogram the bootloader code via ISP, the fuses(lock bits) are all erased again.

 

A thing a lot of bootloaders do is to try to check for a valid application being present, and jump straight to the app if found, unless some button is pressed or link is made, but I think if that was the case the slow flashing thing would not happen.

 

Quebracho seems to be the hardest wood.

Last Edited: Thu. Dec 15, 2016 - 12:54 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think your missing the fact his initial load of flash loads the app and bootloader ($F000) for the 128k part, when placed on the larger 256k part the bootloader code is still at $F000 and not at $1F000......   The vector table would also have the Reset jump to $F000 (bootloader) as well.  It will run, but will be unable to program the flash since it's not located in the bootload memory area for the larger chip. 

 

 

Jim

 

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

ki0bk wrote:
I think your missing the fact his initial load of flash loads the app and bootloader ($F000) for the 128k part

Noted - That's  in the other de-railed thread and I missed that "combo" statement.

 

However I'm not sure you're right about the $F000 (are you an ASM or Pascal guy ?) address. OP says his first attempt at OTA update works but surely the SPM instructions at $F000 are firmly within the Application Section of flash for the 256K part and therefore would not work. Something doesn't ring true here.

 

However we'll probably not solve this because I think the OP has now missed his shipping deadline and is currently getting it in the neck from his boss or perhaps his customer.

 

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

Thanks - I've reached out to them.

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

Hi, it sounds like the part needs to be erased again first. I know when using the AVRISP MkII that the erase check needs to be turned on, otherwise the reprogramming  will not work since programming turns some 1s into 0s. Is there any chance of getting the hex file which flashes the LEDs?

 

Also, I guess you need the specific devkit for the ATmega256RFR2  part. I sent an email yesterday. Thanks

Electronic System Design
http://www.esdn.com.au

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

When you try to run the bootloader the second time, does it appear to be working(i.e. slowly flashing the LED)?

Only if I load it the hex file with the AVRISP. When I used OTAU, the old program keeps running until the new one is received and then it locks up.

 

When you say it locks up after trying the second bootload, does it go back to slow flashing after a power cycle?

No, it goes back to the first program that was loaded with OTAU

 

To be honest, without source for the bootloader(and source for the PC end, do you have that?) you are pretty much screwed. If I had nothing else to do(and tha't about as far from reality as it gets right now), I'd offer to try and disassemble the hex and work out what's happening, but I'd want more than $500, even with the post-stupid-Brexit exchange rates.

That's what I was afraid of, but I'm out of time

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

1. Using ISP, erase the device and program the bootloader stub.

2. Read back the entire contents of the flash and save to a file.

3. Note the fuse bytes.

 

I can't see the fuse bytes in the file, but the AVRISP shows that they're not changing

 

4. OTA bootload your application code as you have been doing and run the application.

5. Connect ISP & read back the entire contents of the flash and save to a file.

6. Note the fuse bytes again.

7. OTA bootload your alternate application code as you have been doing and run the application. (You told us primary app runs and this is the fault)

8. Connect ISP & read back the entire contents of the flash and save to a file.

 

a. Using your favourite difference tool compare the hex files from step-2 and step-5, paying special attention to the bootload area at 0x1F000.

 

bootload area at 0x1F000 is the same

 

b. Also compare the fuse bytes for changes.

c. Using your favourite difference tool compare the hex files from step-5 and step-8, paying special attention to the application area at 0x0000.

 

application area at 0x0000 is the same, and it should be: the only difference between the two applications is which LEDs are activated.

 

Does any of this tell us anything?

 

Thanks

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

"1. Using ISP, erase the device and program the bootloader stub.

2. Read back the entire contents of the flash and save to a file.

3. Note the fuse bytes.

 

I can't see the fuse bytes in the file, but the AVRISP shows that they're not changing"

 

Do this again, but check the lock bits.

Quebracho seems to be the hardest wood.

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

Oh, and is it possible that you could post the Python script you referred to in the other thread? There's an outside chance it could give some insight into your problem.

 

Quebracho seems to be the hardest wood.

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

python otaserverdemo.py -d -p COM3 -i 0x1234 -c 15 -a 0x8555 -t 0x0007 Peer2Peer.bin

 

We've been using this script for years without problem.

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

otaserverdemo.py

 

Is the file you need to post. The command line by itself does not help... Unless, of course the .py file is something that can be found on web.

 

Quebracho seems to be the hardest wood.

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

OK, I see it is available from the web. Had a quick look, can't see any method whereby the PC is checking or verifying programmed blocks, still suspect lock bits or similar, but I have no more time to spend on this right now.

Sorry.

 

Quebracho seems to be the hardest wood.

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

Lock bits look the same each time

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

I must admit to being stumped - but there will be an answer we've just not found it yet.

 

I don't think anyone's asked this yet:

Why the upgrade to ATmega256RFR2 ?

Did your application outgrow ATmega128RFA1 ?

 

A Ha Found it. (Well Messrs Google helped)

 

http://www.avrfreaks.net/sites/default/files/OTA%20Upgrade%20Guide.pdf

 

Contains this statement:

AVR architecture requires Flash programming code to reside in a Bootloader section, but OTA code is too big to fit into this section, so only small programming API functions are placed in a Bootloader section and they are called from the running application.

 

Your production image was updated for ATmega256RFR2  but also your "latest binary" must be updated to call bootloader functions at 0x2F000.

 

Note the higher address for the 256K part

 

Last Edited: Fri. Dec 16, 2016 - 12:44 PM