Ramtron FRAM with the SX

Keith M

Hi,

I'm going to be using some Ramtron serial fram with my SX28.· I've never used any type of external memory, but I've read the datasheet carefully.· It looks pretty straight forward.· The datasheet was a pretty easy read, and for someone with limited exposure to this stuff, that's saying something.

Are there particular gotchas or things to look out for?· I'll be bit-banging the various leads(CS, SCK, SI/SO, and HOLD) and won't be using interrupts to talk to it.· My ISR is busy with some other tasks, and although I could combine them, it might get ugly.

I plan on writing to it at approximately 7.14 mhz, using an asymmetrical clock.· I think my HIGH time is 100ns, and my low time is 40ns.· Anyone see any trouble doing this?· These numbers, and the speed comes as a direct result of the number of instructions required to manipulate the leads.· The write routine, which is the only time-sensitive routine for me, is basically just shifting a byte out, bit by bit using RL, copying C to the port(it's MSB), incrementing a counter, checking to see if I've shifted 8 times, and then looping back.

I plan on setting the chip up first(CS), doing a WREN and a WRITE with the appropriate address, and then putting the chip on HOLD and then just clocking in new data so I keep my successive writes short and sweet.

Any advice, even generic advice regarding serial memory, would be appreciated.

Thanks.

Keith


·

pjv

Hi Keith;

All looks OK to me (I'm using serial FRAMS right now, albeit my clock duty is not quite as short), but unsure why you need the HOLD??

If you leave the clock alone, you can wait as long as you like; the only thing that re-initializes things is dropping CS from a high.


Cheers,

Peter (pjv)

Keith M

Well I don't think I need the HOLD perse.· I think you participated in my thread in another forum about a month ago or so, and we talked about just stopping the clock.

What we came up with basically was that, without hold, noise on the SCK or CS lead could cause a problem.· If you assert HOLD then those leads get ignored while waiting.· In my case, there's about 16us worth of time between bytes that need to be written.· If there was noise on the CS line, that would be fatal, because I wouldn't know to reset CS, resend the two necessary opcodes, the address, etc.

I have enough pins now that using HOLD is easy enough, and I'm throwing it in more just to "do it right" than a feeling that it's really necessary.· If it happens to get in the way, then that's the first thing to go.· I like the Keep It Simple Stupid idea, and getting it to work on a basic level is priority one....

Keith
·

pjv

Hi Keith;

Understood. It's what we call "for greater certainty".

But I'm concerned about your noise. If you are worried that noise may be present on the clock/data lines while the unit is not being actively accessed and that disturbs the operation, then how would you prevent that same noise during accesses, and get corrupted readings? If the exposure to noise is the same, then the corruption issues are the same, no?

Cheers,

Peter (pjv)

Keith M

True.

Honestly, I don't expect any noise.· Although I can appreciate how detrimental noise can be, it's not obvious to me how it might come to invade my setup anyways.· My memory IC will be directly plugged in the solderless breadboard(via a sparkfun PCB adapter), and all the leads from SX to memory will be measured in inches.

Keith

pjv

Well, then in that case, I think your'e away to the races.

I have found noise really not to be a problem unless lines are long (many feet) or if there is a big noise generator around.

Cheers,

Peter

Paul Baker

I think Ive found a good app for the HOLD function of the FRAM,·my current tinkering project (because I have the components and limited funds currently) is creating a FRAM·& MMC interface (both SPI), where the FRAM is used as a temporary buffer to store the 512 byte blocks the MMC requires. When the temp buffer in FRAM is full, instead of reading in a value from FRAM then writing it to MMC, how about getting them to communicate with each other? This requires the SI of one to be connected to the SO of the other, and the method of operation goes something like this:

Setup FRAM to read data byte at address
Before clocking data out of FRAM, place it in hold status
Setup MMC to write a byte of data (block write mode)
Take FRAM out of hold status
Clock the data bits from FRAM to MMC
Repeat for 512 bytes

This should speed up the operation for both SX and Stamp controllers, and with proper programming, no data should every be lost in the event of a power failure. The diagram for the setup is below, a + is a connection of two lines, a E is a crossover w/o connection of two lines. Im hoping this will be my first submission to the Projects forum.

              SX
          |___________|
           | | | | | |   ______
    _____  | | | | | +--|CS    |
   |F  SI|-+-E-E-E-E----|SO  M |
   |R  SO|---+-E-E-E----|SI  M |
   |A SCL|-----+-E-E----|SCL C |
   |M HLD|-------+ |     ------
   |   CS|---------+
    -----
 
 

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·1+1=10

pjv

Hi Paul;

Agreed, a good and proper use for HOLD. Don't forget though, the FRAM lines must be in a particular state before hold may be asserted.

Good luck on your project.

Cheers,

Peter (pjv)

Paul Baker

Thanks, yeah I reread that this morning, the clock needs to be low entering and exiting hold status, plus one other pin needs to be low when exiting, but cant remember off the top of my head (doc's @ home), thanks for the heads up.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·1+1=10

Keith M

I managed to solder the SMT memory chip onto a Sparkfun board along with the header pins. First surface mount stuff I've ever done. I've checked for continuity and shorts and everything appears OK, but things are going too well, so there must be something wrong.

I need some easy way to test that I didn't fry anything, but the most straightforward, I think is to do a RDSR maybe. But this assumes EVERYTHING is working bidirectionally, if I get no response, was the request formed wrong? Or receiver portion not reading correctly, etc?

Keith

Keith M

I hate to reply to my own question at 1:09am EST, but SX/B to the rescue!

I'm successfully communicating with the FRAM using SHIFTIN and SHIFTOUT in SX/B. Now this is running at the goofy standard 83kbps, but its working!

This stuff is way too easy [noparse]:)[/noparse] I'm still in shock that my soldering job, which may look kind of ugly, actually works.

I've got HOLD and WP tied high, and using just four pins, CS, SI & SO, and SCK.

Very cool.

Bean

Keith,
How about posting that code. I'd love to see it.
Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95

http://www.parallax.com/detail.asp?product_id=30012
Product web site: www.sxvm.com
Available now... SX-Video OSD module $59.95 www.sxvm.com

"I'm a man, but I can change, if I have to, I guess"
Red Green
·

Keith M

Bean,

Here it is:

 pause 2000
 
 CS = 0
 SHIFTOUT SI, SCK, MSBFIRST, 6  'xmit WREN opcode
 CS = 1
 
 pause 500
 
 CS = 0
 SHIFTOUT SI, SCK, MSBFIRST, 2  'xmit WRITE opcode
 SHIFTOUT SI, SCK, MSBFIRST, 0  'xmit zero hibyte
 SHIFTOUT SI, SCK, MSBFIRST, 1  'xmit lobyte
 SHIFTOUT SI, SCK, MSBFIRST, 25  'xmit random value (goes into addr 1)
 SHIFTOUT SI, SCK, MSBFIRST, 30  'this should go into address 2(chip auto-inc's for each successive write)
 CS = 1
 
 pause 500
 
 CS = 0
 SHIFTOUT SI, SCK, MSBFIRST, 3  'xmit READ opcode
 SHIFTOUT SI, SCK, MSBFIRST, 0  'xmit zero hibyte
 SHIFTOUT SI, SCK, MSBFIRST, 2  'xmit lobyte
 SHIFTIN SO, SCK, MSBPRE, result
 CS = 1

 BREAK

This is rough first round test code, so forgive the format.

The pauses were thrown in because I was too lazy to look up what the minimums were, etc, they can certainly be reduced, and possibly eliminated.

Notice the opcodes are "magic" numbers, in that they are fixed values that are covered in the datasheet. They are specified in binary, but decimal is just so much more compact [noparse]:)[/noparse]

For my test, I just WATCH'd result and examined the contents at the breakpoint.

Oh, and SI, SCK, CS are all from the memory chip perspective --- they are tied to the named leads on the actual chip.· This is why you see me SHIFTOUT'ing to SI, and SHIFTIN'ing from SO.

Keith

Paul Baker

hmm, I thought the docs specified that write enable bit, WREN, is reset after each opcode which is denoted by transitioning CS back to high. If Im correct, you shouldn't have CS=1 on the 4th line.

<edit> Nevermind, I was wrong, from the docs: "Sending the WREN op-code will allow the user to issue subsequent op-codes for write operations.·... Completing any write operation will automatically clear the write-enable latch and prevent further writes without another WREN command." (emphasis added by me), So your code is correct </edit>

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·1+1=10

Post Edited (Paul Baker) : 10/5/2005 3:47:30 PM GMT

Keith M

Right. And besides, "A falling edge on /CS MUST occur prior to every op-code."

This code actually works so I'm guessing its relatively accurate.

Keith

Paul Baker

Ive got a question regarding the Docs for the serial FRAM, it states that SPI modes 0 and 3 are supported, and proceeds to show all examples in Mode 0. If using Mode 3, does the SCK need to be low for the assertion of the HOLD signal or does this get reversed in light of it being in Mode 3? (I realise likely noone outside of Ramtron would have the answer to this question, but I thought Id ask anyways).

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·1+1=10

pjv

Paul;

I'm not sure; why not just try it?

Cheers,

Peter (pjv)

Paul Baker

Will do, Ill report back when I determine the answer.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·1+1=10

Paul Baker

Ok I was confusing SPI modes, both 0 and 3 clock the data in on rising edge at the slave, so the bit about SCK being low for HOLD is still true.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·1+1=10