Fram tips please.

[granddad]

Any code(C) tips on using a SPI Non-Volatile FRAM Breakout - 2 Mbit / 256 KBytes - MB85RS2MTA , please. I'm using a PIC18F57Q43 .(Nano dev bd ) MPLABX 6.5 ​

Edit... currently getting no RX data back on a Read Status Register ( missing RX clocks ? )

 

[Pommie]

The datasheet shows that you need to read a second byte to get the data. Could this be the problem?

Or did I misread it?

Mike.
Edit, BTW, that is a very nice chip.
edit2, there's an Arduino library for it, https://github.com/christophepersoz/FRAM_MB85RS_SPI

 

[granddad]

read a second byte to get the data.

Thanks , I did get a second byte working sort of ( a read) , but still no data on the MISO .. the decoder said " a write was still in progress " but cannot get to repeat the message now I'm still trying to get my grey cells round the SPI , maybe trying too many things at once ! Back to rtfm..

 

[granddad]

A partial result . mainly by trial and error.. very much a work in progress ... ( MISO PPS as input was in error )
Q can SS be low all the time as I ran out of IO ?
Edit, I have captured the device ID , now working on getting the ram addressed read and write.

 

[Pommie]

Q can SS be low all the time as I ran out of IO ?

I'm not sure, maybe. However, you will have a problem if your compile interrupts a transmission as the two devices will be out of sync.

Mike.

 

[granddad]

Answered my own Q .. Fram seems to need SS to transition for each command, to work in single byte write or read ( sequential multiple W or R are possible with SS staying low ) . I am not able to assign SS to an SPI controlled available IO pin, Only ports A or D, and they are all taken ( 43 IO on this PIC ! ) , so had to control SS after each command. MISO from the module is only driven to 3.3v , but does not seem to be a problem with PIC threshold set to TTL levels. Addresses are 18 bits / 3 bytes, fortunately XC8 has built in 24 bit variables ( __uint24 __int24 )

 

[Nigel Goodwin]

Why not use an I2C FRAM (as I do), then you only need 2 I/O lines - and they are used exactly like normal EEPROM's, except you can leave out the usual EEPROM write delays.

 

[granddad]

Why not use an I2C FRAM

Was just the speed ( up to 40M ) and the 5v operation. really, also not done anything much with SPI so a bit of a education .

 

[Nigel Goodwin]

Was just the speed ( up to 40M ) and the 5v operation. really, also not done anything much with SPI so a bit of a education .

Why do you think you require that speed?, I2C is pretty fast anyway.

 

[granddad]

Speed , don't need Mega speed currently 1Mhz , but 2Mb / 4Mb Fram capacity is useful as intended as a ram disk attached to my PIC/ Z80 playground

 

[Ian Rogers]

Unfortunately CS / SS is definitely required on memory SPI devices.. Microchip, I believe, supports 1.5Mbps on the I2C bus. So not quite as fast.

Is there any way you can squeeze another pin.. Read this.. I have mentioned this before on here.

https://edn.com/wp-content/uploads/1.10.08.pdf

 

[granddad]

squeeze another pin.

Thanks for the link, may come in useful .. the PIC18F57Q43 and nano curiosity board PPS is a bit restrictive with the output port options for SPI, SS only on ports A and D and I am using them for the Z80 SRAM address and F for data . SS / CS via the normal port IO seems to work fine ?

 

[Ian Rogers]

On SPI the pin isn't dedicated... Only in slave mode.. It can be ANY pin in master mode..

 

[granddad]

Only in slave mode.. It can be ANY pin in master mode..

Thanks, Ok will try it.??

 

[Ian Rogers]

Here is my SPI library.. It was written for a pic18 but it should work.

You wont need delays for fram

 

[tumbleweed]

On SPI the pin isn't dedicated... Only in slave mode.. It can be ANY pin in master mode..

Ian's right for a pic with an MSSP peripheral used in SPI mode, but in many newer devices they have replaced the MSSP with individual SPI and I2C peripherals that work a bit differently, and the 18FxxQ43 is one of them.

On these you can have the SPI master assert control of the SS output automatically but then you are limited on which pins you can use since the SS output is mapped via PPS. If you want to control the SS output as a general IO pin in software, then don't map the SS PPS output... leave the IO pin mapped to LATxy and control it yourself.

Unfortunately, Ian's code in post #15 is for an MSSP peripheral and won't work on these devices.

 

[granddad]

peripherals that work a bit differently, and the 18FxxQ43 is one of them.

18F57Q43 Definitely a case of rtfm with everything ! , with this Curiosity Nano board, also don't assume devices / ports start with a ' clean slate ' some are preset . via PPS .. so trying to use them as a port is not on ..' programmers ' have to clear port PPS assignments , ( perhaps clear everything ).

Q ... So if you only have one SS pin on your 'vintage' PIC how do you as Host / Master, control multiple SPI devices , other than IO or with multiple SPI peripherals . guess you could multiplex the SS .

 

[tumbleweed]

Q ... So if you only have one SS pin on your 'vintage' PIC how do you as Host / Master, control multiple SPI devices , other than IO or with multiple SPI peripherals . guess you could multiplex the SS .

With devices like the Q43 that have the "auto controlled" SS feature, you could always map/remap the SPI SS via PPS to different pins for multiple SS outputs, but that's probably more bother than just disabling the auto SS and doing it with IO in code to begin with. Plus, you don't have the PPS restrictions that way.

The auto feature is probably good if you're using DMA.

 

[Ian Rogers]

Unfortunately, Ian's code in post #15 is for an MSSP peripheral and won't work on these devices.

It wasn't really intended for that... The SPI eeproms have a horrible interface with wip's and well's to really get under your skin.. The program just needs the SPItransfer changed to suit..

 

[tumbleweed]

The program just needs the SPItransfer changed to suit..

Yeah, that and the init function to setup the SPI peripheral.

Never really had a problem with the SPI eeproms. You do have to set the write enable latch, so it is a little different than an I2C eeprom, but I've never had to add addtl delays