ashtian01 / optiboot

Automatically exported from code.google.com/p/optiboot
0 stars 0 forks source link

EEPROM r/w support #94

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
Here is two diffs for enable EEPROM support.

 - Fixes bug from Issue #65
 - Adds extra EEPROM page r/w code
 - Still complied to 256 words if LED_START_FLASHES=0 and LED_DATA_FLASH=0
 - Tested on Freeduino with atmega328p

Original issue reported on code.google.com by av1024@gmail.com on 1 Jan 2014 at 2:29

Attachments:

GoogleCodeExporter commented 8 years ago
Hi,

If I apply this diff and compile new bootloader (in this case for atmega1280) 
then the fusebit will change ??

Original comment by Robert.T...@gmail.com on 3 Jan 2014 at 9:55

GoogleCodeExporter commented 8 years ago
Hi,

For mega 1280 code size is 506 bytes (instead of 496 bytes for mega328). So no 
fusebit changes required. 

I prefer to make changes in default fusebits to keep EEPROM on clear memory and 
use custom makefile for writing flash/eeprom on my mega328 so I don't know what 
actual bits used for 1280 :(

Original comment by av1024@gmail.com on 3 Jan 2014 at 10:21

GoogleCodeExporter commented 8 years ago
I can't get the bootloader produced to be under 512bytes with any of the 
compiler versions I have around (4.3.2, 4.6, 4.8...)  What version are you 
using?

Original comment by wes...@gmail.com on 17 Jan 2014 at 8:35

GoogleCodeExporter commented 8 years ago
Hmm.  This doesn't look right:
+        //AV: moved:
+        if (address < NRWWSTART) 
__boot_page_erase_short((uint16_t)(void*)address);
+        if (address >= NRWWSTART) 
__boot_page_erase_short((uint16_t)(void*)address);

that's equivalent to a unconditional call of __boot_page_erase_short() at that 
point.
(also, setting NRWWSTART to 0 no longer results in smaller code.)

Original comment by wes...@gmail.com on 17 Jan 2014 at 8:59

GoogleCodeExporter commented 8 years ago
[deleted comment]
GoogleCodeExporter commented 8 years ago
Agree. Monkeypatching causes original side effects ))

But: a) It's worked (may me only for my chip?), and b) Looks like original code 
does the same as I can see (line 531). Generally I don't understand why we 
needed to delay-or-not delay page erase, may be I dont know something...

     // If we are in RWW section, immediately start page erase
     if (address < NRWWSTART) __boot_page_erase_short((uint16_t)(void*)address);

      // While that is going on, read in page contents
      bufPtr = buff;
      do *bufPtr++ = getch();
      while (--length);

      // If we are in NRWW section, page erase has to be delayed until now.
      // Todo: Take RAMPZ into account (not doing so just means that we will
      //  treat the top of both "pages" of flash as NRWW, for a slight speed
      //  decrease, so fixing this is not urgent.)
      if (address >= NRWWSTART) __boot_page_erase_short((uint16_t)(void*)address);

Original comment by av1024@gmail.com on 17 Jan 2014 at 11:28

GoogleCodeExporter commented 8 years ago
I use gcc 4.7.2 from ubuntu 13.10 repo:
Try omit LED_DATA_FLASH=0 flag and check optimization flags from makefile:

==
make atmega328 BAUD_RATE=57600 SUPPORT_EEPROM=1 LED_START_FLASHES=0
...
avr-size optiboot_atmega328.elf
   text    data     bss     dec     hex filename
    494       0       0     494     1ee optiboot_atmega328.elf
avr-objcopy -j .text -j .data -j .version --set-section-flags 
.version=alloc,load -O ihex optiboot_atmega328.elf optiboot_atmega328.hex
avr-objdump -h -S optiboot_atmega328.elf > optiboot_atmega328.lst
==

Original comment by av1024@gmail.com on 17 Jan 2014 at 11:35

Attachments:

GoogleCodeExporter commented 8 years ago
Adding to #7:
 With LED_DATA_FLASH=0 code size will be 502 bytes...

Original comment by av1024@gmail.com on 17 Jan 2014 at 11:37

GoogleCodeExporter commented 8 years ago
6.0 adds EEPROM read/write support for big chips (1284p, etc), lazily using the 
avr-libc eeprom functions.  This doesn't come close to fitting in 512 bytes 
(606 bytes on 1284p)

I never did get the patch to fit in 512bytes on m328; perhaps it uses an older 
source version...

Original comment by wes...@gmail.com on 28 Jun 2014 at 9:30

GoogleCodeExporter commented 8 years ago

Original comment by wes...@gmail.com on 28 Jun 2014 at 9:38