PROP & SRAM problem

TC · 2013-03-30 10:28

Hello all,
I am trying to get back in the feel of programming. I am working on a program that has no value for me except for remembering how to program again. But I am a little stuck and need some assistance.

I am trying to get the PROP to work with ST Microelectronics M48T35AV. It is a 256K (32K x 8) SRAM that also has an onboard real-time clock, with battery and crystal in one package.

Right now I am just trying to read the Battery OK flag (BOK). I dont think it is working; I am getting the same result every time I power down, and turn it back on. Even though the address changes.

I dont know if it is my code, or that the PROP does not have the speed to keep up with the MAX timings that the SRAM requires.

What is being displaied on serial terminal after three tries:

Address $D415
Data before %10110100
Data after %11111111
Battory OK

Address $869D
Data before %10110100
Data after %11111111
Battory OK

Address $F7E5
Data before %10110100
Data after %11111111
Battory OK

Thank you

CON
        _clkmode = xtal1 + pll16x                                               'Standard clock mode * crystal frequency = 80 MHz
        _xinfreq = 5_000_000

{ Data Input/Output Pins }
  DQ0 = 0       'Input/Output data LSB (right-most)
  DQ7 = 7       'Input/Output data MSB (left-most
  
{ Address Pins }  
  A0  = 8       'Address LSB
  A14 = 22      'Address MSB
  
{ Control Pins }  
  E   = 24      'Chip Enable    ** 1= disabled    , 0= enabled    **
  G   = 25      'Output Enable  ** 1= outputs off , 0= outputs on **
  W   = 26      'WRITE Enable   ** 1= read        , 0= write
  
   
OBJ
  Debug         : "PC_Debug"
  RR            : "RealRandom"
  Pause         : "clock"


PUB Start

  Inlt
  Debug.start (460_800)
  BOK
  repeat

  
PUB Inlt

  DIRA[A14..A0] := %111111111111111                     'Set address pins to output
  DIRA[E] := 1                                          'Set chip enable pin to output
  DIRA[G] := 1                                          'Set output enable pin to output
  DIRA[W] := 1                                          'Set WRITE pin to output
  
  OUTA[E] := 1                                          'Deselect chip
  OUTA[G] := 1                                          'Disable outputs
  OUTA[W] := 1                                          'READ                                          '

PUB Read (Address,Data)

  DIRA[DQ7..DQ0] := %00000000
  OUTA[A14..A0] := Address
  OUTA[E] := 0
  OUTA[G] := 0
  OUTA[W] := 1
  Data := INA[DQ7..DQ0]
  Reset

PUB Write (Address,Data)

  DIRA[DQ7..DQ0] := %11111111
  OUTA[A14..A0] := Address
  OUTA[E] := 0
  OUTA[W] := 0
  OUTA[G] := 1
  OUTA[DQ7..DQ0] := Data
  Reset

PUB Reset

  DIRA[DQ7..DQ0] := %00000000
  DIRA[E] := 1
  DIRA[G] := 1
  DIRA[W] := 1                         


PRI BOK | i,Data1,Data2

  rr.start
  i := rr.random  
  Read (i, Data2)
  Write (i, !Data2)
  Read (i, Data1)
  rr.stop  

  debug.str(string("Address "))
  debug.ihex(i,4)
  debug.newline
  debug.str(string("Data before "))
  debug.ibin(Data2,8)
  debug.newline
  debug.str(string("Data after "))
  debug.ibin(Data1,8)
  debug.newline
  
  if Data1 <> Data2
    Write (i, Data2)
    debug.str(string("Battery OK"))
    debug.crlf
  else
    Debug.str(string("Battery not OK"))
    debug.crlf

kwinn · 2013-03-30 11:32

This is a Static RAM chip so those max times are the guaranteed maximum delay times for the chip to perform the function. For instance the TAVQV (address valid to output valid) max of 100nS means that the longest time between placing a valid address on the ram address pins and having valid data on the ram output pins is 100nS.

This is an old chip so the battery in the SNAPHAT is probably dead. Try writing data to all or most of the memory chip and reading it back to see if it stays the same. A simple memory diagnostic would be to write hex 55 (01010101) and hex AA (10101010) to alternate locations in all 32K and then read them back to see if they are the same.

TC · 2013-03-30 11:50

Thank you, I will give that a try.

Clock Loop · 2013-03-30 11:54

The sram timing might not like spin delays. Datasheet says 100ns read and write timing cycles are required.
Any timing smaller than 100 Khz (10us) you need to do it all in PASM. (at least all sram interfacing)

TC · 2013-03-30 12:18

That is what I was thinking. I just tried a simple write/read and all i am getting for an output is %11111111, even though I put in $55 for a write.I think I might have to find something else to learn on.

Thank you both for your help.

whicker · 2013-03-30 12:19

I haven't looked at your code in high detail, but you made a statement that isn't correct (that far too many people believe).

"I dont know if it is my code, or that the PROP does not have the speed to keep up with the MAX timings that the SRAM requires."

Maximum works the other way, that in this case if the propeller chip spin code was going too fast and exceeded the maximum timing of the SRAM. (not happening here).
There is no minimum access time on parallel access SRAM. Never was and never will be.

You can never go "too slow". You can connect switches, and and long as you make sure to debounce the signals, manually control the operation of the SRAM over minutes/hours. It's completely static, hence the name.

my analysis:

However, your read and write signalling could be incorrect, I've not looked deeply at that. It makes me cringe to see the direction (W) being set after the chip select signals go active.
Your write section is pretty much entirely backwards. Let me tell you what you're telling the chip to do...

1) the SRAM chip output data bus is probably in HI-Z state.
2) You're setting the DQ7..DQ0 pins on the Prop to output direction, and outputting whatever is in the OUTA register (probably 0).
3) Setting E low so soon, you're telling the chip to kind of read but not really, since output enable is at 1.
4) You're setting W (R/w) to Write. Now the SRAM chip has to transition from read to triggering the write action (receiving what is at its data pins).
5) You're setting G to 1, but it's already at 1. (The SRAM chip probably has grabbed what is on its data pins by now).
6) You're finally setting the data values of the outa register. The chip may have already received the 0 or whatever OUTA was, since you transitioned E and W.
7) You're calling "Reset".
8) The first thing "Reset" does is tristate the values at DQ7..DQ0. this further botches the write. The value you wanted to write was barely there.
9) You set the DIRECTION of E to 1. Not the value, but the direction. E is still outputting a 0.
10) You set the DIRECTION of G to 1. it's already set for output.
11) You set the DIRECTION of W to 1. it's already set for output.
12) you still have the SRAM in write mode.
13) then you go to read, and the read process does not work at this point because the signalling is set up wrong (E and W are at 0 still).

Also, the way you are calculating battery OK is a little bit weird. What you're testing for is... Read the value at a random address, write the inversion of the value read back to the same address, and then read the value at that same address again... Test to see if the value first read does not equal the second value read. Which even being at all 1's is different from before, thus the code says It's okay. (really? may want to fix this test so that it fails if it's not the exact inversion)

TC · 2013-03-30 12:45

Doesn’t matter now, I have removed the SRAM from my breadboard and started on something else. I think I was biting off more than I can chew. But thanks anyway.

Toby Seckshund · 2013-03-30 13:48

A 32k x 8 SRAM should be within all of the number of pins available and then just bit banging it. I looked up that chip and it is the 3.3 Volt variant of the two. Cluso managed to get about 2Mb worth running with minimal latches, I tend to used the DracBlade circuit and have discrete latches (or the same in CPLD form). I have a bunch of thse types of battery backed RAMS, in a drawer, but I bet that their batteries expired a long time ago.

I wonder if the bread-board was you problem, they are "good" for poor contacts and high capacitance. But having said that I have had stuff running on them even with ridiculous lengths of jumper wiring! Spin should help by slowing things down.

Alan

whicker · 2013-03-30 14:58

TC wrote: »

Doesnt matter now, I have removed the SRAM from my breadboard and started on something else. I think I was biting off more than I can chew. But thanks anyway.

Yikes.

All you needed to do was reorder some of the instructions based on the timing diagrams in Figure 5 (read) and Figure 7 (write).
That and you confused DIRA with OUTA... that's all...

well, good luck on future projects. Spin does make stuff simple and is plenty fast.
I've used it to successfully clock colors out to RGB led strings, talk with Lego Mindstorms over infrared, talk with various game controllers, and program flash RAM blocks.

TC · 2013-03-30 15:53

whicker wrote: »

All you needed to do was reorder some of the instructions based on the timing diagrams in Figure 5 (read) and Figure 7 (write).
That and you confused DIRA with OUTA... that's all...

If you would’ve said that first I would’ve understood you better. From your last post all you could find were my mistakes, but give no idea on what should I be doing. I am trying to get out of my comfort zone (I can make some cool LED patters) and I had that chip lying around. I have trouble seeing what I should be going on with the data. If you could see my breadboard you would see that every pin has an LED on it so I can see things happening. I use to be real good at this until my accident, now that part of my brain doesn’t work like it did.

I have now directed my attention to a 240x128 monochrome display. Not for a project, but to exercise my brain.

Thank You

PROP & SRAM problem

Comments