Mega4809 memory mapped Flash reading

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

This is a split from my thread here JS https://www.avrfreaks.net/commen...

 

 

About memory mapped Flash, does the datasheet actually state that it's the case for this chip?

And since RAM is from [0..0x1800[ and the flash is 48k the only start values that make sense is somewhere between  

[0x1800..0x4000].

There must be some things that for sure will be odd.
As I know this is the first AVR where flash aren't 2**n in size so the PC size match the flash side.
That is not the case for this chip, so what happen when rjmp cross the "end's" (The compiler have a flags for using that) ?

 

Add:

Ok I did not plan to make a thread out of this :) (I don't use the chip)

But from those that do I guess it make sense. 

And from #2 it's clear I was partly wrong.

 

Last Edited: Fri. Jun 15, 2018 - 07:53 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I will need to split this, the memory map seems to indicate that the some of the code space is visible in the data space.

 

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

You're right, the PC must be 15 bit to address the 48KB (24 Kwords). So what happens if we load the PC with a value between 0x6000 (24k) and 0x7FFF (32k -1), since these values are outside valid flash?

 

edit: to test this, maybe the contents of those addresses could be dumped with lpm for analysis. I'm betting they will read as 0xFF, 0x00 or (special bet) 0xC5.

Last Edited: Thu. Jun 14, 2018 - 10:53 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So the trick here is to subtract 0xC000 (48K or 49152) from the pointer. The chip has 48K of flash

ldi      zl, low ((Button_pressed * 2) - 0xC000)
ldi      zh, high ((Button_pressed * 2) - 0xC000)
rcall    MSG_OUT_0_MM                              ; Use memory mapped flash mode

it's the same for the Tiny817 but we subtract 0x8000 (32K or 32768) from the pointer even though the chip has only 8K of flash

ldi      zl, low ((Button_pressed * 2) - 0x8000)
ldi      zh, high ((Button_pressed * 2) - 0x8000)
rcall    MSG_OUT_0_MM                             ; Use memory mapped flash mode

I tried to find something in the .inc file to make it automatic but I gave up at the end.

 

edit and because the thread was "started" by sparrow2 you need to mark this as the solution. laugh

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

Last Edited: Fri. Jun 15, 2018 - 04:41 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

js wrote:

So the trick here is to subtract 0xC000 (48K or 49152) from the pointer. The chip has 48K of flash

ldi      zl, low ((Button_pressed * 2) - 0xC000)
ldi      zh, high ((Button_pressed * 2) - 0xC000)
rcall    MSG_OUT_0_MM                              ; Use memory mapped flash mode

it's the same for the Tiny817 but we subtract 0x8000 (32K or 32768) from the pointer even though the chip has only 8K of flash

ldi      zl, low ((Button_pressed * 2) - 0x8000)
ldi      zh, high ((Button_pressed * 2) - 0x8000)
rcall    MSG_OUT_0_MM                             ; Use memory mapped flash mode

I tried to find something in the .inc file to make it automatic but I gave up at the end.

 

edit and because the thread was "started" by sparrow2 you need to mark this as the solution. laugh

Suppose you have a flash address 0x1000 (byte address). It is mapped at 0x1000+0x4000 = 0x5000.

So you need to ADD 0x4000 at the (byte) address. 

The (- 0x8000) in the tiny example uses the 16bit overflow. It should be (+ 0x8000) in fact.

Your (- 0xC000) uses 16bit overflow too. It should be (+ 0x4000)

This is just weird and obfuscated. A beginner won't understand this, even if you claim it's the flash memory size.

It's all about the OFFSET, not the actual memory SIZE.

For an atmega3208 with only 32K flash what would you do? Subtract 0x8000 because it's the flash memory size? Wrong.

 

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

Have you used this? Do you have an example? Maybe then one could use the defined MAPPED_PROGMEM_SIZE and add it to the pointer instead of subtracting it?

 

I'm actually doing some work now, maybe I'll try this tomorrow.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

js wrote:
the memory map seems to indicate that the some (sic?) of the code space is visible in the data space

The image posted seems to indicate that all of the code space is visible in the data space ?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sure but where do you put your code then if it's all data? wink

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

not just in data - it's also in data!

 

Is this the ultimate code bloat - doubles the size!!

 

surprise cheeky

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The main thing is that now you can use LD(s) ST(S) to get flash so memory copy can be the same for RAM or FLASH. (if the compiler use it that is an other question), but like the Xmega's the registers aren't memory mapped so there is a code bloat.

 

Add

As long the sum of ram+flash+eeprom+IO <=64K there is no bloat! just an extra way to get the same thing. (And my guess is that's the reason for 4809 and not 6409)

Last Edited: Fri. Jun 15, 2018 - 11:42 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:
memory copy can be the same for RAM or FLASH

presumably, you can't just copy from RAM to Flash ?

(or even from Flash to Flash).

 

Does any compiler "know" that, or is it up to the user to understand?

 

there is no bloat! just an extra way to get the same thing

Yes, of course - it was a joke! 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:
Does any compiler "know" that
Well presumably the data you place in flash is "__flash" and that modifier also requires that "const" be used. So, yes the compiler will warn you about any attempt you make to write TO flash in any way. (which is presumably why Georg-Johan arranged for __flash to have the const requirement too ;-)

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

But what if you attempt to write to the "RAM" area which "mirrors" the flash?

 

The point of that mirror is that you don't need to mess with __flash or suchlike ... ?

 

Does it "know" that this is not real RAM?

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:
But what if you attempt to write to the "RAM" area which "mirrors" the flash?
But (in C) how do you achieve that? The best you can get away with is going to involve a warning about "discards const" so it's not like you are not going to be told! Consider this for example

#include <avr/io.h>

const __flash uint8_t text[] = "hello";

uint8_t * ptr;

int main(void) {
    text[2] = 'X'; // will not be allowed as direct write to const
    ptr = &text[2]; // warning expected here
    ptr[0x4000] = 'X';
}

that yields:

D:\atmel_avr\avr8-gnu-toolchain\bin>avr-gcc -mmcu=atmega16 -Os avr.c -o avr.elf
avr.c: In function 'main':
avr.c:8:13: error: assignment of read-only location 'text[2]'
     text[2] = 'X'; // will not be allowed as direct write to const
             ^
avr.c:9:9: warning: assignment discards 'const' qualifier from pointer target type
     ptr = &text[2]; // warning expected here
         ^

So the write to "const" got the expected response and in trying to create a "writable pointer" I get a warning telling me "const" is being lost

Last Edited: Fri. Jun 15, 2018 - 12:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It should be (+ 0x8000) in fact.

Your (- 0xC000) uses 16bit overflow too. It should be (+ 0x4000)

This seems to be correct, at least for the M4809 and the Tiny817, I'm using the defined MAPPED_PROGMEM_START instead of a number and it works for both chips.

 


ldi        zl, low ((Button_pressed * 2) + MAPPED_PROGMEM_START)
ldi        zh, high ((Button_pressed * 2)  + MAPPED_PROGMEM_START)
rcall      MSG_OUT_0_MM             ; Use memory mapped flash mode

anyone with some other chip may want to try it.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly