1

I'm a beginner in C language. I'm trying to operate on EEPROM memory in my ATmega 8 and ATtiny2313. Based on this tutorial I've created the following codes:

1) writes a number to place 5 in uC's eeprom

#define F_CPU 1000000UL
#include <avr/eeprom.h>


int main()
{
    number=5;

    eeprom_update_byte (( uint8_t *) 5, number );

    while (1);
    {
    }
}

2) blinks the LED n times, where n is the number read from place 5 in eeprom

#define F_CPU 1000000UL
#include <avr/io.h>
#include <util/delay.h>
#include <avr/eeprom.h>


int main()
{
    DDRB=0xFF;
    _delay_ms(1000);

    int number;

    number=eeprom_read_byte (( uint8_t *) 5) ;

    for (int i=0; i<number; i++) //blinking  'number' times
    {
        PORTB |= (1<<PB3);
        _delay_ms(100);
        PORTB &= (0<<PB3);
        _delay_ms(400);
    }

    while (1);
    {
    }
}

The second program blinks the led many times, and it's never the amount which is supposed to be in eeprom. What's the problem? This happens in both atmega8 and attiny2313.

EDIT: Console results after compilation of the first program:

18:01:55 **** Incremental Build of configuration Release for project eeprom **** make all Invoking: Print Size avr-size --format=avr --mcu=attiny2313 eeprom.elf

AVR Memory Usage

Device: attiny2313

Program: 102 bytes (5.0% Full) (.text + .data + .bootloader)

Data: 0 bytes (0.0% Full) (.data + .bss + .noinit)

Finished building: sizedummy

18:01:56 Build Finished (took 189ms)

Lexander
  • 184
  • 2
  • 10
  • The code `PORTB &= (0< – Sir Jo Black May 21 '15 at 15:54
  • Why not combine your write/read code in just one compilation unit? That would at least rule our that you do not overwrite your EEPROM when you are flashing the other firmware. From what I can tell that is most likely the thing happening. Erased EEPROM data is 0xFF, so your LED would blink "many times" like you pointed out. Double-check fuses. – Rev May 22 '15 at 06:21

1 Answers1

2

That is one of the every time failures for beginners :-)

If you compile simply with avr-gcc <source> -o <out> you will get the wrong results here, because you need optimization! The write procedure MUST be optimized to fulfil the correct write access! So please use '-Os' or '-O3' for compiling with avr-gcc!

If you have no idea if your problem comes from read or write the eeprom, read your eeprom data with avarice/avrdude or similar tools.

The next pitfall can be, that you erase your eeprom section if you program your flash. So please have a look what your programmer really do! A full chip erase erases the eeprom as well.

Next pitfall: What fuses you have set? You are running with the expected clock rate? Maybe you have programmed internal clock and your outside crystal seems to be working with wrong speed?

Another one: Just have a look for the fuses again! JTAG pins switched off? Maybe you see only JTAG flickering :-)

Please add the compiler and programming commands to your question!

Klaus
  • 24,205
  • 7
  • 58
  • 113
  • Ok, I've set optimization settings to Os, I'm sure I have fuses set properly. I've added compilation results to the quiestion, but I don't know how to disable eeprom erasing during uploading the hex; when I mark "inhabit auto chip erase", Eclipse (because that's my IDE) doesn't erase flash data and shows errors with verification of uploaded hex. – Lexander May 21 '15 at 19:01
  • Are you running with avr-gcc? Are you working under linux? If so, please do not use any IDE. Please go with command line tools until you fixed these problems. Take a look for avrdude to programm your chip. Which programmer you have? If you can't see which commands are executed from your IDE I will not be able to help! – Klaus May 21 '15 at 19:42
  • Why is Os/O3 optimization required to properly write EEPROM? From what I recall I did it with various other optimization levels (at least while JTAG debugging). I think it really shouldn't break the code, at least the timing restrictions aren't that tight IIRC. – Rev May 22 '15 at 06:16
  • It must not be O3, but as I remember minimum O2. I have no idea why someone should use O1 and O2? If optimization breaks the code, then the code is wrong. And if optimization is required, why not use the maximum? Optimization is required for eeprom write access if the code is written in C. If you use code from a precompiled library this one must compiled with Ox or it uses assembler for the job. Accessing the two eeprom registers for a write access written in C without optimization fails because of two many instructions between both accesses. – Klaus May 22 '15 at 14:48
  • Ok, Thank you guys. I use Eclipse with gcc toolchain plugin on Windows, it has Os optimization mode set by default. Eeprom works, but is set to 0xFF in every cell during uploading the compiled hex. I don't know how to disable this, but it doesn't bother me. Everyting except this works fine, thanks again – Lexander May 22 '15 at 19:35
  • For disabling eeprom erase while uploading you have to configure fuse bit. – zviad Jun 14 '16 at 08:15