FRAM settings

[FFMan]

I've got one these http://www.ramtron.com/files/datasheets/FM25H20_ds.pdf arriving tomorrow to play with.

I'm looking at the SPI bit flags on P182 of the reference manual and wondering how best to set these up.

The device says it supports to 40mhz, so on my 29mhz 128a1 f/4 should work, then i could try setting double speed mode once proven ? Have I understood this correctly ?

Any idea what the clock phase and idle settings should be ? The documentation says it supports mode 0 & 3, so why not mode zero = 00

I'll use h/w SPI

Best to use MSB or LSB first, for ease of reading data back ? or does it not matter so long as the data comes back the way it was sent ? Documentation states MSB for addresses.

Active low chip select it states in the documentation.

Once running I'll post up some write rates and findings for interest.

Gradually answering my own questions and editing the post.

[dkinzer]

The device says it supports to 40mhz, so on my 29mhz 128a1 f/4 should work, then i could try setting double speed mode once proven ? Have I understood this correctly ?

That is correct.

why not mode zero = 00

That is what I would use.

Best to use MSB or LSB first, for ease of reading data back ? or does it not matter so long as the data comes back the way it was sent ?

The bit order would not matter for data as long as you are consistent. However, the commands and addresses must be sent in the bit order expected by the device. The diagrams at the bottom of the above-referenced datasheet clearly indicate that the device is expecting MSB first. This is confirmed in the second paragraph on page 5.

There is some example SPI EEPROM code for the AT25256A that may help you get started. The FM25H20 command protocol is almost identical to that of the AT25256A, the only difference being that the FM25H20 requires three address bytes rather than just two.

[spamiam]

That looks like a great FRAM chip. There is a whole new generation of them since I last used them.

re: MSB or LSB first for transfers, I'd not worry too much about it. Just send it out in the same way you plan on reading it back.

One technique would be to have the address of the value you are sending and the sizeof() that value. The same would apply to a structure or array.

Then starting at the zero-th byte of the address, send a byte, then increment the pointer to the address of the source and send the next byte. Continue this by incrementing the source pointer until all bytes are sent.


To go the other way, have a pointer to the zero-th byte of the destination, and read a byte and store it at the pointer, incrment the pointer and repeat.

The transferring function does not need to know what is most significant or least significant as long as the source and destination are the same.

-Tony

[dkinzer]

[...]the only difference being that the FM25H20 requires three address bytes rather than just two.

One other difference is that the FM25H20 is not a paged device. In the example code subroutine WriteSPI_EEPROM() there is some code to handle the page boundary (CS/ must be deasserted at each page boundary). For the FM25H20 the "write" code would be similar in structure to the "read" code, doing continuous operations without regard to a page boundary.

In the example code, the addrEEPROM parameter would need to be changed to an UnsignedLong, of course, if you wanted access to the full EEPROM.

[FFMan]

re spamians comments - i thought i read that if you send a start address you can just keep sending data and the address increment is done internally ? (hopefully likewise on the read).

This keeps the traffic down and suits my intended use as a data dump. I guess in time i might introduce some segmentation but for now its just a linear dump area i want.

[dkinzer]

i thought i read that if you send a start address you can just keep sending data and the address increment is done internally ?

That is correct. Once you send an address, it is maintained in internal registers in the device and incremented after each operation. Note, however, that once CS is deasserted, an address must be sent along with the next read/write command.

I believe that Tony was referring to addresses in AVR RAM, perhaps assuming that you would collect a series of datapoints in RAM and then write them to the external EEPROM.

[spamiam]

I believe that Tony was referring to addresses in AVR RAM, perhaps assuming that you would collect a series of datapoints in RAM and then write them to the external EEPROM.

Correct. The FRAM module will automatically increment its pointer for reads or writes until /CS goes high. So, you only need to send the opcode for read/write and the 18 bit starting address. Then stream the data until you are done. As long as /CS is held low, then you can pause between bytes for as long as you want without having to send a new address to the FRAM.

-Tony

[FFMan]

I'm still battling to get this fram chip working. In order to eliminate my home-made break-out board from the equation, i ordered a couple more and got them professionally soldered to breakout boards by provantage.
I have one hooked to a 128a1 as follows:-

Pin - Fn - 128a1 pin

1 - /S - F4
2 - Q - F6
3 - /W - NC
4 - VSS
5 - D - F5
6 - C - F7
7 - /Hold - 3.3v
8 - VDD - 3.3v


I'm trying the simplest of operation to prove connectivity - read the status register using this code

Code: Select all

	sleep (0.5)

	debug.print "Open SPI"
	Call OpenSPI(3, 0, f.4)
	debug.print "opened"

	dim inByte as byte,outcmd as byte = 5
	Call SPICmd(3, 1, outcmd, 1, inByte)
	debug.print "RDSR=" & inByte

The documentation http://www.ramtron.com/files/datasheets/FM25H20_ds.pdf states on page 7 that bit 6 of the register is always set 1 so I should not get a null byte back but I do :-
ZBasic v3.3.4
Open SPI
opened
RDSR=0

My write test also fails.

I have a 10k pull-up to /s but this doesn't make any difference.

Can anyone see what might be wrong please?

[dkinzer]

Can anyone see what might be wrong please?

The channel specified for OpenSPI() is not related in any way to the particular SPI controller that will be used. The ZBasic System Library manual description for OpenSPI (second page) says:

For devices that have multiple SPI controllers (e.g. xmega-based devices), the most significant byte of the flags parameter specifies the index of the SPI controller to use (0=PortD, 1=PortC, 2=PortE, 3=PortF).

Try this code:

Code: Select all

Const spiChan as Byte = 1
Const ctlIdx as Byte = 3
Const csPin as Byte = f.4
Const spiFlags as byte = &H00

Sub Main()
    Call OpenSPI(spiChan, MakeWord(spiFlags, ctlIdx), csPin)
    Dim inByte as byte,outcmd as byte = 5
    Call SPICmd(spiChan, 1, outcmd, 1, inByte)
    Debug.Print "RDSR="; inByte
End Sub

[edit: corrected the SPI channel number]

[FFMan]

I tried this code thanks (the clue IS in the documentation !). On first run I got rdsr=204 which seems like a plausible value, but as in desparation last night i had switched MOSI and MISO so i decided to switch them back and see what I got. RDSR still was 204 - hmmn.

So i disconnected MOSI & MISO still got 204 returned so I guess its erroneous.

I tried disconnecting my 10k pullup on chip select too but that made no difference either.

The rest of the test program goes on to write 10 characters to the fram then reads them back. All 10 reads return character 204. Naturally the read write routines aren't proven yet so it may mean nothing.

Is 204 a value you might expect to get with no device attached ?

Any ideas ?

(I have a spare mounted fram if you feel the the inclination to have a play for me ?)

[dkinzer]

Is 204 a value you might expect to get with no device attached ?

Not particularly. If the MISO line were not being driven I would expect a "noise" value unless it had a pullup or pulldown on it.

I have a spare mounted fram if you feel the the inclination to have a play for me ?)

I'd be happy to take a look at it. I tried the code that I posted earlier today on a ZX-128a1 with an Atmel AT25256A attached and got the expected result (32). I think that the Ramtron device is supposed to be similar (with the exception of a wider address register).

[edit: the correct expected result is 64, using a valid SPI channel number produces this result]

[FFMan]

thanks don - i'll drop a mounted one and spare IC in the post to you in the next day or so.

I'm sure you'll make sense of it.