7 Replies Latest reply on Jan 2, 2019 3:53 PM by ShivendraS_56

    where can I find FM25V02 FRAM Linux Driver


      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.

        • 1. Re: where can I find FM25V02 FRAM Linux Driver



          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,


          • 2. Re: where can I find FM25V02 FRAM Linux Driver

            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.

            • 3. Re: where can I find FM25V02 FRAM Linux Driver


              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)?





              • 4. Re: where can I find FM25V02 FRAM Linux Driver

                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?

                • 5. Re: where can I find FM25V02 FRAM Linux Driver

                  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.




                  • 6. Re: where can I find FM25V02 FRAM Linux Driver

                    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)



                            uint8  WAddrL, WAddrH;



                            // FM25V02 ADDR: 0x000000 ~ 0x007FFF.

                            // FM25V05 ADDR: 0x000000 ~ 0x00FFFF.

                            // FM25V10 ADDR: 0x000000 ~ 0x01FFFF.

                            // FM25H10 ADDR: 0x000000 ~ 0x03FFFF.

                            WAddrL =   WAddr & 0x000000FF;

                            WAddrH = ((WAddr >>  8) & 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]);




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

                                    if (!(ret % num+3))


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





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

                    • 7. Re: where can I find FM25V02 FRAM Linux Driver

                      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.