Peculiar mega128 SPM behaviour (CPU Bug ?)

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

I found a peculiar bevaviour when fiddling with some bootloader code.

My bootloader is progamming the Flash from an external 512kB SRAM. This SRAM is mapped in (and paged) at 0x8000-0xFFFF.

I have a function to fill each flash page for the SPM. This includes setting the RAMPZ depending on which Flash page I'm going to program.

It all goes well, until I fill a page that is using data from the LAST 256 bytes of RAM.

The loop looks like this (wp is a word ptr to the data) :

    
for (i = 0; i < nWords; i++, wp++)
        SpmBufferFill(i, *wp);

When wp is 0xFF00, the last tour through the for loop will cause the pointer to wrap to 0, although it's never accessed at that value.

When this happens, the page programmed will be all FF's !!!

As a test, I tried decrementing wp by 2 before the loop, so it will not wrap, and everything was fine again.

It seems the wrapping causes the problems, perhaps it's affecting RAMPZ or something.

It sure is weird.

I worked around the problem by copying the RAM block to a local internal RAM block before the loop.

Have anyone had similar problems, or done any obervations that shows a similar behaviour ?

I will contact Atmel, to hear what they have to say about this one.

/Jesper
http://www.yampp.com
The quick black AVR jumped over the lazy PIC.
What boots up, must come down.

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

Sounds like the Z pointer is not properly set at page write, causing you to write to a different page than expected. Perhaps the ram access is done with the Z pointer?

-Geir

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

No, SpmBufferWrite properly sets up the Z pointer for each write.
I program about 80 kB, and it fails at exactly those two pages where the ext RAM buffer wraps.

Also, the page_write and page_erase uses the same command logic and the same variable pointing out the page. If there was a Z problem, the erase should also fail, which it doesn't.

The name RAMPZ is suspicious as it's short for RAM Page Z Select Register. However, it's never used for anything refarding RAM, but solely to select which 64K Flash Page to use for the SPM instruction.

I could imagine that automagically modifying the RAMPZ register on a Z-register wrap would be a hidden "feature".

/Jesper
http://www.yampp.com
The quick black AVR jumped over the lazy PIC.
What boots up, must come down.

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

It's not hidden at all; this is from the instruction set manual, on LDD Z+:

The RAMPZ Register in the I/O area is updated in parts with more than 64K bytes data space or more than 64K bytes Program memory, and the increment/decrement/displacement is added to the entire 24-bit address on such
devices.

-Geir

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

Thanks for the (Z) pointer, Geir, this is obviously the problem.
RAMPZ was set before the copying and apparenly was modified by the wrap. The workaround perhaps used the X or Y pair instead, so the problem didn' occur.
I didn't have time to dig into this, so I didn't read longer than the datasheet.

However, there seem to be some confusion in the ST desctiption :
"The RAMPZ register in the I/O area is updated in parts with more than 64K bytes data space, and the displacement is added to the entire 24-bit address on such devices. For devices with more than 64K bytes program memory and up to 64K bytes data memory, the RAMPZ register is only used by the ELPM and ESPM instructions. Hence, RAMPZ
is not affected by the ST instruction." ????
If it's updated, how can it not be affected ? ;-)
Wonder what they really mean.

/Jesper
http://www.yampp.com
The quick black AVR jumped over the lazy PIC.
What boots up, must come down.

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

what they really mean:
For devices with up to (less than or equal to) 64K bytes data memory:
The RAMPZ register in the I/O area is updated (affected).
in parts with more than 64K bytes data space:
RAMPZ is not affected (updated) by the ST instruction.

It is unfortunate that English can be so confusing. Spend some time on a technical service hotline trying to explain owner's manuals and you will wish some other language were used.

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

I can NOT suggest german in that case. I tried to explain my asm code to someone at university and we switched to englich after 10 mins.

Christoph

I tend to post off-topic replies when I've noticed some interesting detail.
Feel free to stop me.

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

I still not sure what they mean, but you missed the point.

The LD Z+ instruction updates the RAMPZ when the Z pointer wraps from FFFF to 0 (or the other way). So why does the ST + instruction NOT affect RAMPZ when the Z pair wraps ?

Why write at all that the RAMPZ is updated, if it's not.
They could just have written that paragraph at the LD instruction (which they did) and leave it out at ST (which they didn't).
Atmel sure knows how to obfuscate a datasheet.
It's generally pretty good, but the part about the RWW and NRWW section is a wonderful example. The must be a better way to describe that ;-)

I still think there's something rotten.

Another funny thing I just realized was that the SPM code I' using (which comes from the Ethernut project) is using SPM and not ESPM !!
According to the datasheet, it should only be able to program the first 64 kB.
Luckily, it has never read the datasheet and programs my full 100kB for code without problems !

Now THAT is weird !

/Jesper
http://www.yampp.com
The quick black AVR jumped over the lazy PIC.
What boots up, must come down.

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

You must have some old pdfs, I find no reference to ESPM in my mega128 datasheet nor in my instruction set manual. SPM is used (with RAMPZ) to program the entire memory space.

And the text on RAMPZ and ST is the same as for LD

-Geir

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

geir wrote:
You must have some old pdfs, I find no reference to ESPM in my mega128 datasheet nor in my instruction set manual. SPM is used (with RAMPZ) to program the entire memory space.

At least a couple of years old, yes. It's not present in the 1997 instruction set manual I've got (not surprising really, given that SPM isn't present either...). The first reference I can find is in the June 1999 release, but then there's a gap in my collection between 2000-2001, and when I pick up the instruction set history again in 2002, ESPM has gone. So somewhere between late 1999 and early 2002 is when ESPM and SPM got combined.

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

Yes, it's an old instruction set manual allright. Shouldn't matter.
My Z-80 Manual is from 1979, and it's still current :-)

But, I assumed that this was the case, as the SPM worked exactly as it should (well, as the ESPM should ;-) ).
ESPM opcode was given as 95F8, SPM as 95E8
In the new manual, SPM is still 95E8, but the description of the instruction is from the "old" ESPM instruction.

And apparenly, in the new instruction set manual, the text "Hence, RAMPZ
is not affected by the ST instruction" is not there anymore in the LD and ST desctiptions.
That's great, because I'm pretty sure that was incorrect.

/Jesper
http://www.yampp.com
The quick black AVR jumped over the lazy PIC.
What boots up, must come down.