NetBurner Community Forum

I'm having a weird problem with the FFS. When making calls to other drivers that use the SPI bus, A file that is open for several seconds cannot be closed or flushed because the file system reports a code 8, which is a FILE NOT OPEN error. I know the file is open, the problem only happens when trying to access other devices on the bus. bus access between drivers is protected by a semaphore.

Does anyone know any details about this file system? The source is not included, and supposedly access to the card is routed through mmc_mcf.cpp, but the problem is very strange and I'm wondering if the ffs library tries to access the SPI bus directly without using mmc_mcf.cpp?

Hi,

According to the EFFS manual, you cannot share the SPI with other devices:

2.1.5
Exclusive Use of the QSPI
The EFFS normally requires exclusive use of the QSPI interface. The standard software and drivers operate in this mode. There are also performance reasons for exclusive use. While it may be possible to share the QSPI with other peripherals, it is not supported in the development tool suite.


You might try closing the file before using the spi for anything else, but then you would need to reopen it again, set the working directory, etc.

Yup I asked NB about this some time ago myself, and received a very comprehensive reply; here it is:

> do you have any example code & connection info for
> connecting an SD card to the QSPI interface on the SB-72? I may have
> an application for this and don't have the time right now to dig into the
> pindefs settings etc. especially if it's already been "boilerplated".
>

It could be done with a SB72, but to my knowledge no one has done it
yet. The QSPI DATA IN, OUT, CLK are available, but you would need to
modify the driver code for the write protect and card detect. It might
be possible to do those two with some of the other SB72 GPIO, or you
could always "assume" that the card and write protect don't matter. So,
can it be done? Yes. But, we do not have any examples and you it would
take a bit of effort on your part to implement.


> As I understand it, SD/MMC interfacing requires exclusive use of the
> QSPI interface (read that someplace in the EFFS docs) - can you confirm if
> this is indeed true?

Yes, exclusive use is required if using the file system. We are working
on sharing with the new wifi, which is also spi, and this "could" lead
to a general spi sharing, but I don't feel that I can say it is
guaranteed. We will know more in June.

>On the SB72 it's a moot point since there's no extra
> chip select lines to operate another SPI device but for the MOD5xxx
> platforms I'm wondering if I can get away with hanging anything else on there, along
> with an MMC card...not a show stopper if not possible, but I would like to
> know if the recent improvements to the EFFS implementation did anything to
> address this

That's it - and June is behind us now so I guess it's time to ask again

I would hope they do something to support it, as here is a quote from their ads:
How to Use the Mod5234 in Your Product
The Module can be used as your product's core processor, or as a secondary network processor. It contains the Freescale ColdFire 5234 microprocessor, 2MB Flash memory, 8MBytes of SDRAM and 10/100 Ethernet including the magnetics, led's and RJ-45 connector. One hundred of the processor signal pins are brought out on two 0.1" center 50-pin connectors. These signals include the address bus, data bus, chip selects, interrupt inputs, timers, I2C, QSPI, GPIO, and 3 UARTs. The module measures only 2" x 2.95".

Paul

It's worth note that the standard NB config files for the 5234 eTPU allow pins to be configured as SPI pins. Don't know if the SPI drivers are thread safe but it seems likeky that using OScrit sections and some port pins changes would do the trick for at least one other (if not more) SPI buses. The eTPU examples app note includes an independent SPI interface to a Microchip MCP3304 A2D. Worth a look.

Hello,

We understand that there are those who really wish to do spi sharing. At the moment we have not been able to come up with a method that would be easy to use with the large number of spi devices out there. If there were a straight-forward way to accomplish this, we would certainly have done it. The FAQ below is the current status of sharing the spi with the file system.



FAQ: Sharing the QSPI with the EFFS on NetBurner Modules
---------------------------------------------------------

1. Does the EFFS require exclusive use of the processor’s QSPI?

Exclusive use is the only supported method of using the EFFS. Sharing the QSPI with other devices is extremely complex and the implementation will vary greatly from one SPI peripheral to another. Essentially each implementation becomes an engineering task particular to the design.


2. Are there any examples of QSPI sharing?

No, each device has different requirements.


3. Are there any other options?

If you are using a Mod5234, the eTPU signals can be configured as a SPI port. There are also external devices such as the NXP SC18IS602/602B which is an I2C to SPI bridge chip.


4. Is it possible to implement QSPI sharing myself?

Yes, but please be aware that we cannot support that effort. The source code for the SD card QSPI driver is located in c:\nburn\<platform>\system\mmc_mcf.cpp.


5. Do you have any recommendations?

Basically what you need to do is check if the SPI bus is free before using it. If it is free then you need to make sure it is properly configured for the device. Anything else at the EFFS level, such as open files, should be irrelevant since the SD card will just be in a
stalled state.

One possible strategy is to create a structure that contains all of the configuration settings for each specific QSPI device, one of them being the SD Card. This structure should contain all of the general configuration registers for this peripheral as well as the settings for each of the queue configuration registers. You can find the configuration settings for the SD Card in the "int spi_init (void)" except for the actual SPI clock speed.

The clock is first set to the lowest speed possible, about 100KHz. Then when the card is mounted the driver will communicate with the card and check its rated speed. After a successful mount the QSPI speed will be set. This value can change for various cards.

The EFFS uses the function "void spi_set_baudrate (unsigned long br)" to set the QSPI baudrate. You might want to add code in this function to save this new baud to the structure you made to remember your QSPI configurations for the SD Card.

You then need to use an OS object to protect the SPI bus, such as an OSMbox, since you can pass data with these objects. Assign each SPI device a specific ID and store it in the mailbox. The places you pend on this OS object should be at the beginning of the functions that accesses the bus. For example, from "C:\Nburn\MOD5234\system\mmc_mcf.cpp", put the protection at the beginning of the "spi_cs_lo" and post the object at the end of "spi_cs_hi". This works at the CS level for the SD card since the CS is asserted and deasserted via GPIO at the beginning and end of each transfer. When using the general QSPI driver (qspi.h) the CS is asserted by the peripheral after each word is transferred. You will need to set the pend and post is the proper places in your code to completely protect the entire QSPI transaction.

Now combine your OS protections and your stored settings structure for each device. First pend on the Mbox. Then once you successfully gain control of the OS Mbox, check the value in the mailbox. If this value is the same as the ID assigned to the current SPI device then continue on to use the peripheral. If the ID is different then you need to load
the correct settings for your device into the QSPI registers. These device specific settings should be stored in the structure mentioned earlier. Then write the current device ID into the mailbox to specify how the QSPI is currently configured. Now you can continue on to use the peripheral.

Although this is a late post.... I've written a QSPI driver that supports an unlimited number of CSs and an unlimited transfer size. It is limited to byte transfers and should be very suitable for storage type devices (I've used it to interface to several non-volatile RAMS). The automatic CS feature of the QSPI is not used. The CSs are all controlled via GPIO. Only 1 device can be used at a time. Before beginning a transfer, the QSPI is configured to meet the requirements for that particular device (baud, delays, CS active/inactive, etc). It seems to work well and have used it in systems that support 6 SPI devices (without multiplexing hardware). Certainly seems like this may work for the EFFS.

bb