What happens if an out of range address is used with eeprom_write_byte (and eeprom_read_byte)?

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

I just discovered a typo in a bootloader application I wrote several years ago.  I haven't seen any problems as a result, but I want to understand the implications better.

 

The bootloader uses a few bytes at the top of eeprom memory to blink an LED.  If the application failed to load, the bootstrap codes blinks the LED as defined by the blink code.

 

Since the bootloader and application it loads are compiled separately, I had to hard code the addresses at the top of eeprom memory to use (at least that's the only way I could figure out how to do it). 

 

The chip is an atmega328p which has 1K eeprom.  So, the last byte of eeprom is 0x3ff.  

 

Here's what I coded:

<code>

#define ADDR_APP_RUN        (uint8_t *)0x3ff
#define ADDR_BLINK_CODE     (uint8_t *)0x3fe
#define ADDR_BLINK_COUNT    (uint8_t *)0xefd

</code>

 

The 0xefd for ADDR_BLINK_COUNT is a typo.  It should have been 0x3fd.

 

The same code fragment is used in both the bootstrap loader and the application(s) it loads.   After an application is loaded, it does things like check for expired license, clock tampering, etc, and writes a blink code to eeprom if something is not right.

 

This all seems to work (and has for several years), but I'm thinking the app is writing the "blink count" somewhere in the middle of eeprom memory, instead of 0x3fd.  Maybe I haven't gotten "bit", since if a blink code gets written, the application will have to be reloaded anyway.

 

But, I'd like to know where the byte is actually getting written.  Will the higher order bits of the address just get truncated somewhere in the eeprom_write_byte and eeprom_read_byte code?  Or will the address be modulo 1K?  Something else?

 

Thanks for any insight!

 

 

 

 

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

davethomaspilot wrote:
Will the higher order bits of the address just get truncated somewhere in the eeprom_write_byte and eeprom_read_byte code?
Not in the code, but in the hardware registers the address is written to.

davethomaspilot wrote:
Or will the address be modulo 1K?
Why "or"? Isn't that simply the same as "higher order bits of the address just get truncated "?

Stefan Ernst

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

sternst wrote:
Why "or"? Isn't that simply the same as "higher order bits of the address just get truncated "?

 

Yeah, you're right.

 

I was thinking modulo 1K would mean I'd still be writing to the address (0x3fd) I intended.  But, instead 0xefd becomes (0x2fd).  

 

Is that correct?  

 

Not so bad--the app would have to have 765 bytes of EEPROM before the "blink count" would overwrite it.  (Besides the fact that the app would have to be reloaded anyway).

 

Is this "for sure", or is there a way I can verify what EEPROM address gets written?

 

Thanks!

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

Write some test code to see what happens!

I'd expect the extra bits to be truncated, so modulo 1k.

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

The EEprom adress registers only seems to have 10 bits implemented.

AVR's also do not have a memory controller.

So a simple wraparound seems the most logical.

 

But I would advise to write a small test program.

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com

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

davethomaspilot wrote:

Is this "for sure", or is there a way I can verify what EEPROM address gets written?

 

1)  If the board has an ISP connection, use an ISP programmer to read out the EEPROM.

 

  or

 

2)  Write a application program that reads the eeprom contents and sends it to a PC via USART.

 

 

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

Interesting to pull the datasheet for some device where EEAR does not use all the bits. Almost at random I picked 2313 because it has 128 bytes of EEPROM. The datasheet says:

In which the "unused" bit 7 is described differently to the rest. I wonder why it is even R/W? (or is that a doc error?). You'd have thought they'd default that bit to 0 and make it R only? Or in the logic that accesses the EEPROM array that this bit from EEAR simply would not be wired into the logic for addressing? The fact that it "always reads 0" seems to suggest that it is hard wired to Gnd anyway.

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

clawson wrote:
I wonder why it is even R/W?

Check the text again -- bit 7 is apparently valid in the 4313 family member.

 

Similarly, OP should look at the datasheet for the AVR model in question:

I guess it doesn't flat-out come out and say that the unused bits are always zero--but it comes pretty close.

 

Doesn't exactly the same discussion ensue with SRAM and flash?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Thanks for the replies.

 

As far as writing a test program... 

 

How to do that?  I can already read the data I write to the 0xefd address using the same "bad" address for the read.  I guess I could try reading using 0x2fd and see if that gets the same result as when I read from 0xefd. 

 

I'll hook up the ICE and look at EEPROM.  I should be able to spot the bytes that are not "0xff' pretty easily. 

 

Thanks!

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

To test erase flash (so all 0xFF) then run code to write non-0xFf to "invalid" address then use ISP to read out whole EEPROM and see "what you hit". Probably masked version of invalid address.

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

It accesses 0x2fd, as predicted.

 

Thanks your your replies!