where can I find FM25V02 FRAM Linux Driver

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
sashc_3923966
Level 1
Level 1

I am currently using FM25V02 FRAM Over SPI. I followed the changes suggested in one of the thread to change the spi-nor.c file but the kernel log says unable to read JEDEC DATA.

0 Likes
1 Solution

Hi,

The Linux driver support for the SPI FRAM provided via KBA223028 ​​​verifies against the first three bytes of the device ID received . Since the device ID read in fm25v02a always returns MS bytes first, of which first three bytes are 0x7F, 0x7F, 0x7F similar to the first three bytes of cy15b104q; hence, the manufacturing part number field doesn't directly correlate with FRAM variants. In this case you only need to update the text field to fm25v02a. There can a possibility of contention when two or more FRAMs are connected to the same SPI bus because all will return identical 3-byte device ID. Are there two or more F-RAMs connected in your system by any chance? 

If the Linux driver is unable to read and verify the device ID of the FRAM at all, a possible issue could be with the underlying host controller which is unable to access the F-RAM. Is HOLD pin of the FRAM correctly configured on the hardware (when accessing, it must be pulled high or driven to high if it is controlled via the host controller IO)?

Rgds,

Shivendra

 

View solution in original post

0 Likes
7 Replies
PradiptaB_11
Moderator
Moderator
Moderator
500 replies posted 250 solutions authored 250 replies posted

Hi,

Currently we do not have a driver specifically for FRAM. The suggested way to add compatibility via Spi-nor.c as discussed in KBA223028

Did you add F-RAM-specific device ID to the list of supported devices in spi-nor.c.

Thanks and Regards,

Pradipta.

0 Likes

Yes I added the details as per suggested thread.

{ "fm25v02a", INFO(0x7f7f7f, 0, 32 * 1024, 8, 0) },

I added the above details. But I am not aware if it is correct for FM25v02A. Can u let me know the correct values?

After adding these details The linux is unable to read the device info under mtd.

0 Likes

Hi,

The Linux driver support for the SPI FRAM provided via KBA223028 ​​​verifies against the first three bytes of the device ID received . Since the device ID read in fm25v02a always returns MS bytes first, of which first three bytes are 0x7F, 0x7F, 0x7F similar to the first three bytes of cy15b104q; hence, the manufacturing part number field doesn't directly correlate with FRAM variants. In this case you only need to update the text field to fm25v02a. There can a possibility of contention when two or more FRAMs are connected to the same SPI bus because all will return identical 3-byte device ID. Are there two or more F-RAMs connected in your system by any chance? 

If the Linux driver is unable to read and verify the device ID of the FRAM at all, a possible issue could be with the underlying host controller which is unable to access the F-RAM. Is HOLD pin of the FRAM correctly configured on the hardware (when accessing, it must be pulled high or driven to high if it is controlled via the host controller IO)?

Rgds,

Shivendra

 

0 Likes

No Our board contains only 1 FRAM. I checked using DSO. I can see the write and read signal correctly. FRAM is responding correctly. but when I write something on FRAM and read the same address I can only get "0x00" at that location. I am using the WREN Command before writing the actual data . the code that gets transmitted is "02 00 00 61" 02 is for WREN and 0x00 and 0x00 for the address and 61 is the ascii value for 'a'. I am writing only 1 char of 'a' and reading the same address. The FRAM responds and give the value 0. the WPn (Write protection)pin is also high during the write cycle. Is this correct or it should be LOW during the Write cycle?

0 Likes

Hi Sarfaraz,

Thanks for sharing details. Please make sure you execute the WREN opcode, 06 before sending write command 02, 00, 00, 61.

The WREN sets the WEL bit in the status Register for enabling the memory write via WRITE opcode.

To transmit the WREN, you must do the following

1- Drive CS low

2- Transmit WREN

3- Drive CS high.

The WREN command, as described above, must be executed  before every write to either memory (WRITE) or register (WRSR). The WEL latch clears at the end of write cycle with CS high.

To verify whether WEL but in SR is setting or not, you can execute the RDSR (05) to read the SR.

I hope this helps.

Thanks,

Shivendra

0 Likes

Thanks for your reply. I am sending the 0x06 before sending the above data. Below is my function to send the data to FRAM

void FM25V02_WRITE(uint32 WAddr, uint8 *pBuf, uint32 num)

{

        FM25V02_WREN();

        uint8  WAddrL, WAddrH;

        // FM25V02 ADDR: 0x000000 ~ 0x007FFF.

        // FM25V05 ADDR: 0x000000 ~ 0x00FFFF.

        // FM25V10 ADDR: 0x000000 ~ 0x01FFFF.

        // FM25H10 ADDR: 0x000000 ~ 0x03FFFF.

        WAddrL =   WAddr & 0x000000FF;

        WAddrH = ((WAddr >>  😎 & 0x0000007F);

        printf("L:%.2X \n" ,WAddrL);

        printf("H:%.2X \n" ,WAddrH);

        uint8 txz[15] = {0};

        uint8 rxz[1] = {0};

        memset(txz , 0 ,sizeof txz);

        memset(rxz , 0 ,sizeof rxz);

        memset(xfer , 0 , sizeof xfer);

        txz[0] = WRITE;

        txz[1] = WAddrH;

        txz[2] = WAddrL;

        uint32 ret;

        for(ret = 0;ret < num;ret++)

                txz[ret+3] = pBuf[ret];

        xfer[0].tx_buf = (unsigned long)txz;

        xfer[0].len = num+3;

        ret = ioctl(spi_fb, SPI_IOC_MESSAGE(1), &xfer[0]);

        printf("write:");

        for (ret = 0; ret < num+3; ret++) {

                if (!(ret % num+3))

                        puts("");

                printf("%.2X ", txz[ret]);

        }

        puts("");

        FM25V02_WRDI();

Am I missing something important here. I am able to read the data from fram but it is always 0x00

0 Likes

Hi Sarfaraz,

Thanks for sharing the program details. I believe the function "FM25V02_WREN()" is transmitting the WREN opcode 0x06 in the code before write cycle initiates which is the correct sequence if that is the case.

The SPI packet formation for the write command is in the correct order. Hence, there is not an issue with the protocol as long as underlying controller is transmitting the data bytes in the same order. I would suggest putting a scope/LA and monitor the transmitted bytes for both WREN opcode and WRITE opcodes.

You can insert the read status register (RDSR, 0x05) immediately after FM25V02_WREN() to check whether the status register read returns with value 0x02 (WEL bit set set to 1). If the WEL bit is not set, it will inhibit the FRAM write. 

Other quick check can be reading the RDID and match the first few bytes to confirm whether the FRAM device is responding at all. Unfortunately, the SO pin is not driven (remains tri-stated) until the device drives with a valid output data. So, reading 00 may not always reflect a valid output. To check whether FRAM device really drives the SO to 0 during read, you can connect an 1K pull up on the SO pin and if FRAM still reads 00 then FRAM is actually driving the SO during read.

Other debug tips

1- Check if the HOLD pin is biased to logic high. Floating HOLD pin or driven to a logic LOW prevents device access.

2- Block protect bits (BP0 and BP1) of the status register are 00. A non zero value means some or all memory array is write protected.

3- System and SPI GND pins are connected to common GND plain.

4- Any signal glitch, specially either on SCK and/or SI line can latch the wrong input, thus an invalid output.

Thanks,

Shivendra

0 Likes