Use of 'at'

[LGR]

I'm trying to keep a timer in a Ramtron FRAM chip, which is like an eeprom except that with 10^14 write cycles, I can read and write every second for hundreds of years. To do this, I declared a couple of DWORD (32 bit) variables RTC1 and RTC2. In order to read and write these 32-bit numbers to the FRAM, which wants 8-bit bytes, I tried something that I thought I saw somewhere:

Code: Select all

var  RTCA1 : array[4] of byte at RTC1;  // Map run time counters to array
RTCA2 : array[4] of byte at RTC2;  // for FRAM read/write

It was my understanding that by doing this, it would map the 4-byte array right over the top of the 32-bit word, and so all I would have to do to read/write the counters RTC1 and RTC2 is index reading and writing bytes through the arrays RTCA1 and RTCA2.

I tested the FRAM code separately, and it works correctly (the protocol is identical to SPI EEPROM), but when I tried this,

Code: Select all

for i := 0 to 3 do RTCA1[i] := framread(i);
      for i := 4 to 7 do RTCA2[i] := framread(i);
      if out1 then inc(RTC1);
      if out2 then inc(RTC2);
      for i := 0 to 3 do framwrite(i,RTCA1[i]);
      for i := 4 to 7 do framwrite(i,RTCA2[i]);

I got essentially random numbers. So I went to the help file, which only talks about using 'at' on bits.

I'm sure I saw something about mapping arrays on top of words and dwords in the forum here, but searching for "at" is pointless. Is this supposed to work, and am I doing it right? Or did I remember seeing something esle?

[janni]

Code: Select all

var  RTCA1 : array[4] of byte at RTC1;  // Map run time counters to array
RTCA2 : array[4] of byte at RTC2;  // for FRAM read/write

It was my understanding that by doing this, it would map the 4-byte array right over the top of the 32-bit word, and so all I would have to do to read/write the counters RTC1 and RTC2 is index reading and writing bytes through the arrays RTCA1 and RTCA2.

That is correct . You may easily check the mapping in Statistics.

when I tried this,

Code: Select all

      for i := 0 to 3 do RTCA1[i] := framread(i);
      for i := 4 to 7 do RTCA2[i] := framread(i);
      if out1 then inc(RTC1);
      if out2 then inc(RTC2);
      for i := 0 to 3 do framwrite(i,RTCA1[i]);
      for i := 4 to 7 do framwrite(i,RTCA2[i]);

I got essentially random numbers.

Probably because you use out of range indexes for RTCA2. Try

Code: Select all

      for i := 0 to 3 do RTCA1[i] := framread(i);
      for i := 0 to 3 do RTCA2[i] := framread(i+4);
      if out1 then inc(RTC1);
      if out2 then inc(RTC2);
      for i := 0 to 3 do framwrite(i,RTCA1[i]);
      for i := 0 to 3 do framwrite(i+4,RTCA2[i]);

[LGR]

Actually, I copied that wrong. What I originally had was what you showed.

So I still have a mystery.

[janni]

I've written simple program to test the principle and everything works fine. Maybe your problem lays elsewhere?

Code: Select all

program test;

var  RTC1,RTC2: dword;
     RTCA1 : array[4] of byte at RTC1;  // Map run time counters to array
     RTCA2 : array[4] of byte at RTC2;  // for FRAM read/write
     i:byte;
     fram: array[8] of byte;

function framread(i:byte):byte ;
 begin
  result:=fram[i];
 End;
 
procedure framwrite(i,b:byte);
 begin
  fram[i]:=b;
 End;

begin
   for i := 0 to 7 do fram[i]:=0;
   while true do
     begin
      for i := 0 to 3 do RTCA1[i] := framread(i);
      for i := 0 to 3 do RTCA2[i] := framread(i+4);
      inc(RTC1);
      inc(RTC2);
      for i := 0 to 3 do framwrite(i,RTCA1[i]);
      for i := 0 to 3 do framwrite(i+4,RTCA2[i]);
    end;
end.

[LGR]

Even though the FRAM procedure passed a simple test, I'm suspicious that it's not completely reliable. I'm going to write a more torturous test for it. It's just a hunch. And it's the nature of this count accumulation that errors will accumulate. Once you have one SPI error in the wrong place, the numbers will be whacky forever.

[LGR]

FYI, I finally got to the bottom of the problem. It wasn't hardware after all. It was not properly switching back and forth between SPI1 and SPI2 using the SPI_SET_ACTIVE procedure.

It seems that the MMC library defaults to SPI2, but doesn't automatically switch to it. So the library works without the SPI_SET_ACTIVE until the FRAM routine is called, and from that time forward, all SPI operations point to SPI1 until you execute SPI_SET_ACTIVE again, pointing it back at SPI2.