How to use Compact Flash in eCos?

[Altera_Forum]

Hi. I'm having problems accessing the compact flash card in eCos. I tried a program that mount the filesystem to / and write a file to it. But the program hangs when I try to open a file. I have run the cf_ide_test that comes with the compact flash ip from this forum. The card is recognised properly. I have also tried to run the fileio1.c test program that is in eCos. I get a -1 error when it tries to mount the FAT fs that's on the CF card. I can read and write to and from it in Windows. It's a brand new card, Kingston Elite Pro High Speed 512 MB.  

 I have read that I need to remove and insert the card again in some cases. I have tried this, but it does not work. Does anyone have some tip to what I might do?  Ole

[Altera_Forum]

The most common cause of error when accessing compact flash from eCos is with using the correct device name. If you have called your device "my_cf" in sopc builder, then you would normally need to use the device name: "/dev/my_cfa/1" (Note the extra "a") in the call to mount(). However it is possible that you have a compact flash card which does not contain a master boot record, particularly if you have had to reformat it after running the cf_ide_test's. In this case you should access the device as "/dev/my_cfa/0".

[Altera_Forum]

I have called the compact flash component for cf in SOPC. I have tried to access /dev/cfa/1, /dev/cfa/0, /dev/cfb/0 and /dev/cfb/1. No luck. I just get these errors: 

<FAIL>: mount() returned -1 Unknown error <FAIL>: chdir() returned -1 No such entity   I have made my eCos library with JFFS2 also, could there be a confilct there? I can't see how that might be. I also get this error when I try to access the CF-card that came with the Nios Development Kit. Any ideas?  Ole

[Altera_Forum]

One other important thing to be aware of is that the compact flash and LCD share pins on the Nios II development boards. If you want to access compact flash, you need to ensure that the LCD is not connected to the board. It doesn't sound like this is your problem, since you were able to access the compact flash using other software. 

 To help debug the problem, you could enable the debug macros in altera_avalon_cf.c and disk.c. The information these produce may help shed light on the problem.  I wouldn't expect JFFS2 to cause any issues. However to be certain that it's not something like that which is causing things to come unstuck, I'd recommend that you create a new project in configtool and follow the steps outlined in the getting stated guide, i.e. just add in the packages listed there. Hopefully that'll get you to a working system, and help you diagnose the problem that you've currently got.

[Altera_Forum]

I think I have found out what the problem was. But not how to solve it. When I use program_flash to program the flash with my program, and the upload the .sof file again from Quartus, then compact flash don't start. But when I use Nios IDE to upload the program into RAM, then the compact flash component starts and I can read and write from the cf. What could be wrong here? I really want to have the hardware design and program in flash so it starts up when I turn on the dev. kit. How do I do this? 

 Ole

[Altera_Forum]

Did you get any further with this? 

 I've just tried it on a modified version of the standard 1c20 example on a 1c20 dev. board, and I've been able to succesfully access the compact flash even when booting from flash.  One thing that I'm doing different from you is that I did this using the pending 5.0 release of the Nios II kit/eCos. However I'm not aware of anything that has changed that would relate to your problem.  If you have no other ideas, then you may want to try this again with version 5.0 of Quartus/the Nios II kit/eCos when they are released (which will be soon).

[Altera_Forum]

I get it to work succesfully when I run it from Nios IDE. We haven't had any need for it to boot from flash lately ,but I will look into it later.

[Altera_Forum]

I have tried some more from flash now. One of the problems is that the compact flash isn't power cycled I think. When I run it from flash I can't mount the compact flash. When I run it from Nios IDE, I just take out the card and insert it again and it works.  

 A couple of other issues: What kind of performance have you got with reading from and writing to the compact flash? With the compact flash card I'm using I should be able to get up to 8 MB/s write speed. I get nowhere near this. I need to have 512 kbit/s writing speed, but I can't get this either. This is used in a datalogger, so I write a couple of bytes at the time. Actually 2 bytes * 8 channels * 4 kHz = 64 kB/s. I basically have a loop that write 2 byte to the spi and read 2 bytes from it. The spi slave is a ADC that can deliever 125 ksamples/s so it is not the bottelneck I think. These 2 bytes are written to a file. Is the fprintf function too slow to make this work? Is there any way to speed this up?   How many files can you have open? I have seen the setting in nios2configtool and it is set to 16 files. But when I try to open 4 files and writing to them, the program just hangs. I would like to have 8 files open and writing to each of them a stream of 8 kB/s. I don't feel this is such a large stream of data, but the program just don't work. I use only 1MB of RAM, but I didn't think that could have anything to do with it.   A couple of no-so-related issues: Sometimes when I run the program from Nios IDE and out on the dev. kit, the program runs once, and after it is finished, it runs a second time. The realtime clock just keeps ticking a the second run. How do I get rid of this?  I run eCos from ROMRAM and I have tried to get around the performance problem described above by writing the samples to a array and then flushing it to the disk. But I can't seem to be able to get the program functioning with a array of 8000 unsigned chars and above. I would like to have 32000 cyg_uint16 preferably, but this doesn't seem to work. I thought I had enough RAM with 1 MB of it, but maybe I should use the 16 MB more that I could access?  Ole

[Altera_Forum]

Your multiple file descriptor problem may be due to re-entrancy. Under eCos, if you try and access the same device simultaneously from multiple threads - you can run into re-entrancy issues. If you are trying to read/write multiple files from different threads at the same time, then you will need to protect the filesystem accesses with a semaphore (or similar) to ensure that the file system does not become corrupted. 

 With your clock problem, how are you reststarting your code? If you are just brancing back to _start, then you need to make sure that you disable interrupts first.

[Altera_Forum]

I have just used a standard main() as my program and none threads. I just want the program to run main() and then quit, but usually it starts again a second time.  

 Just before I read this I tried to use a cyg_uint16 array of 16000 elements and the program can't deal with this. It runs through a couple of printfs and then restarts again. It does this as long as I has bothered to look at it. I does the same under debug. Does it run out of memory?  Ole

[Altera_Forum]

Could be. You can use nios2-elf-size from the comand line to see how much space your elf file requires.

[Altera_Forum]

It doesn't look like the elf file is too big, dec is 301176. But I wonder what kind of performance you have gotten out of writing to the compact flash.  

 What is the function that in theory should be fastest? And is it faster to write for example 100 at a time than 1 byte? Is it so much overhead on the fprintf, fwrite and similar functions that it's not possible to even get close to 1 MB/s writing to the compact flash? I need to get some samples from a ADC via SPI and then write it to disk. 32000 samples from the ADC takes about 0.4 s and these are 16 bit samples. When I combine taking the samples and writing to disk, it uses about 1.4 seconds. That is 1 second to write 64000 byte to the compact flash. That's a little slow I think. I use the Nios II/f processor with hardware multiply in logic elements on an Cyclone chip at 50 MHz.  Ole

[Altera_Forum]

The compact flash driver uses polled IDE accesses rather than the faster DMA modes (since these are unsupported in the hardware). This means that you won't be able to achieve the advertised fastest access rates for a given compact flash cards, however I have seen rates in the order of 600 Kbytes/s for a similar system to the one you're describing. 

 Obvious things to watch out for are:  1. turn on optimisisation in the compiler (this is on by default). 2. not being starved out by other activities, i.e. higher priority threads, ISR's and DSR's. In particular make sure that your system clock tick rate is not too high.  There is an overhead to each call to an access function, so the bigger the blocks you transfer - the better.   Best performance is obtained using the lowest level function that you can get away with, i.e. it is better to use read() rather than fprintf().

[Altera_Forum]

Is it possible for you to disclose how that 600 kB/s was achieved? What kind of packages was used (if any relevant but the standard ones), what kind of function was used and how large blocks was transfered? Was the data written to disk in a seperate thread?  

 When you say read(), you mean write()? I didn't get it to work, but then I've never used it before.  Ole

[Altera_Forum]

About the DMA. DMA is not supported in the eCos port? Will it be supported? I will probably need to make a prototype of this project later and then I can connect to the Compact Flash via DMA. Do you know what kind of performance I can get then? Maybe 2 MB/s to take a wild guess?  

 And do one have to make very large changes to the eCos port to support DMA? Not so large on the Compact Flash driver I believe if DMA was supported by the eCos port. I might get a couple of weeks working full time on this later this summer if that would be a priority for my employer.  Ole

[Altera_Forum]

Sorry, my previously hasty post may have misled you. The transfer rates that we measured were for read access not write. Write may well be slower (because of the nature of flash), but I have no data points there. 

 In our case the compact flash accesses were run in a seperate thread and data was read out in blocks of 4K using fread(). The packages used to manage the compact flash/FAT file system were those listed in the Nios II eCos documentation.  Currently there are no plans to provide generic DMA drivers for eCos. However if a community minded person was willing to submit a driver, I&#39;d be happy to include it in the next release http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/smile.gif   Modifying the compact flash driver to use DMA should be a relatively straightforward task. The altera_avalon_dma component is not too difficult to drive. You can find details of the register interface etc. in the Nios II processor handbook.

[Altera_Forum]

Ok. Then I believe DMA might be the only answer for now. Because what I would have to do with this setup would go something like this: I have to read data into a locked array in one thread and then unlock it, copy it and then write it to disk in another thread. The original array would be filled up again right after it was copied. I&#39;m not that knowledgeable about how many cycles taskswitching and arraycopying takes, but I&#39;m afraid that I wouldn&#39;t gain anything by doing it that way. What I&#39;m doing now is filling up a smaller array, about 200 bytes and then writing it to disk. I have tried with larger arrays, but it was slower. So I have to settle for this until a DMA might be used. 

 Ole

[Altera_Forum]

I tried write() again today, and it works as fast as it needed to. It seems to be about 2-4 times faster than fwrite. So now my application&#39;s fast enough. 

 Ole