Go Down

Topic: Burning a bootloader on new chip (Read 2026 times) previous topic - next topic

TwistedVTX

So I have 2 ARDUINO UNO R3 boards
I am using one as an ISP programmer using the sketch from the IDE program
I select the target board as the ARDUINO UNO and then I select
"burn bootloader
I get a failure and an error and Do not know why or how to fix.
I have 4 brand new ATMEGA328P-PU chips I wish to get the bootloader programmed into it.
Here is the error I got,

 ***failed; 
avrdude: WARNING: invalid value for unused bits in fuse "efuse", should be set to 1 according to datasheet
This behaviour is deprecated and will result in an error in future version
You probably want to use 0xfd instead of 0x05 (double check with your datasheet first).

Any help is appreciated

westfw

Use a bootloader-programming tool like "optiloader" or "Nick's Board programmer" - much easier.

(The "unused bits" errors is a backward incompatability in avrdude...)


krupski

Use a bootloader-programming tool like "optiloader" or "Nick's Board programmer" - much easier.

(The "unused bits" errors is a backward incompatability in avrdude...)


Hey, I've got a quick question for you... in Optiboot, why does flash write need to go from serial to a ram buffer, then from the ram buffer to the boot page buffer?

Why can't it go directly from serial to the boot page buffer and save the bytes used by the intermediate buffering code?

I've currently got Optiboot down to 0x01D4 (468) bytes WITH the ability to also write to EEPROM, but now I'm (for fun) trying to make it even smaller.

Thanks.

Gentlemen may prefer Blondes, but Real Men prefer Redheads!

MorganS

Because you can't write to the buffer that you're currently executing code from?
"The problem is in the code you didn't post."

krupski

Because you can't write to the buffer that you're currently executing code from?
Why the question mark at the end of the sentence? Do you KNOW, or not?

The bootloader does not "execute code" from the buffer. The bootloading process takes in the compiled sketch as serial data, writes it into a temporary ram buffer, then transfers that buffer to a special AVR buffer that the chip uses to program that block of flash memory.

What I want to know is, if that buffer can be filled from a ram buffer, then why can't it be filled directly from the serial read data?

Gentlemen may prefer Blondes, but Real Men prefer Redheads!

MorganS

Yes, but the bootloader is executing from flash memory. It's a while since I looked at that part of the datasheet but I seem to remember that there's only 2 flash blocks on a 328P. So to fill more than half of the flash memory, the bootloader needs to do some tricks to write to the first block.
"The problem is in the code you didn't post."

westfw

Quote
in Optiboot, why does flash write need to go from serial to a ram buffer, then from the ram buffer to the boot page buffer?

Why can't it go directly from serial to the boot page buffer and save the bytes used by the intermediate buffering code?
Hmm.  Good question.   Have you tried it?  Would it save space?  The RAM consumption is irrelevant...


Quote
I've currently got Optiboot down to 0x01D4 (468) bytes
Cool.   The next "important" reduction is to reduce the number of pages it occupies in the soft-uart/virtual-boot-partition images, I think...  Under 512bytes on an ATtiny would be nice...


krupski

#7
Feb 09, 2017, 06:25 pm Last Edit: Feb 09, 2017, 06:30 pm by Krupski
Hmm.  Good question.   Have you tried it?  Would it save space?  The RAM consumption is irrelevant...
Yes I have. The process starts (the TX and RX leds flicker for about 1/4 second) then it fails with a timeout error.

(edit to add): There is no LED (pin 13) blink code in my bootloader. I'm talking about the UART leds. Also tried it on both an UNO (16u2) and Duemilanove (FTDI) - same results.

I was guessing that when the first page of the sketch code is being flashed, the next serial byte(s) coming in were lost due to the boot_spm_busy_wait delay.  But, regardless of where the data comes from (buffer or serial port), the busy wait is executed, so that can't be the problem.

I also thought maybe the serial data had to come from ram, so I tried to do an intermediate

(Serial | Serial << 8) -> uint16_t
,  then uint16_t -> boot_page_fill

That didn't work either.

I still need to test if it's a timing issue. I'll try it at a low baud rate like 2400 or so and see if it then works.

Is it a possibility that the boot_page_fill has to be done fast (that is, each word written within "X" clock cycles)?  Transferring from a buffer to the boot_page_fill is, of course, much faster than serial reads, but I couldn't find anywhere in the data sheet for the 328p about a timing limitation.

I also thought maybe it was an "odd number of bytes" problem, causing the last 16 bit word to not be formed or written to the boot_page_fill, so I experimented with sketches that resulted in both odd and even number of bytes. Still no luck.

I know that "saving ram" (the intermediate buffer) is irrelevant, I'm doing this as an attempt to get the bootloader even smaller (mostly for fun).

Gentlemen may prefer Blondes, but Real Men prefer Redheads!

TwistedVTX

Westfw, So getting back to my question.
I should use one of these "optiloader" or "Nick's Board programmer"
so I just upload either one to my Uno I am using as the programmer
and then put the blank chip in the other Uno and follow Nicks directions?

westfw

Quote
I just upload either one to my Uno I am using as the programmer
and then put the blank chip in the other Uno and follow Nicks directions?
Yep.  I originally developed optiloader when the Uno first appeared, for "upgrading" older Arduinos to use optiboot (and save some space for sketches.)  given the proper cable, you can plug in one empty chip/board after another and get the bootloader on them all really quickly.  See (lame video): https://www.youtube.com/watch?v=YBFUGre0hY4
Adafruit and Nick  have enhanced the concept, added more chips/bootloaders, included options for internal clocking, and etc...


TwistedVTX

I followed Nicks instructions
I burned 4 chips. verified they all upload a sketch on the Uno board

Thank you for your help.

westfw

Thanks for the feedback.  You'd be surprised how often we never learn whether advice was helpful or not :-(

Go Up