Hi Mehdi,
Reading your posts, it is clear that the HW is setup correctly (as the bareboard project works).
One thing I noticed (and had issues with myself, recently): You should indeed open the correct spi port, and indicate the proper CS line.
For CS1 (on master) use "spifd = fopen ("spi2:2", NULL); (The number after the colon indicates the CS lne to use - see MQX I/O Driver User's Guide)
For Slave, it should not matter, as there is only one SS line (mapped to the CS0 pin) - you might try indicating it anyway ("spi1:1")
This part all hinges on whether MQX4.0 drivers support SPI in slave mode, and I have not had confirmation or denial from MQX, nor have I seen in the docs if this is so.
When it comes to the coding I did, it was quite complicated...
We had data *pouring* in the SPI port (in slave mode).
I looked at the MQX code (source is included in the MQX folders) and created a new driver (modeled on the master driver using DMA).
This driver used ping-pong DMA to constantly move data into large buffers.
When a buffer was full, I used an ISR to update the DMA (to point to a new next buffer), chain the full buffer into a buffer queue, and post a semaphore to let the application code know it had a new buffer of data available.
This was done on a K60 processor, so we have that in common.
This also required DMA programming and using the DMA interrupt to notify application code, etc.,
BTW. The MQX drivers are also configured so you can use DMA for SPI I/O
The only way I could know for sure if MQX 4.0 supports slave mode SPI on the K60 would be to look into the source code, or get a statement from MQX person(s).
The code has been changed considerably from 3.8.
I really do not have the time to dig into the code deeply enough to find out. I did a quick look, but it was not immediately obvious.
If you do have the time, the driver code is in: mqx/source/io/spi
You might even consider using the debugging in CW and step into this code and follow the execution - especially what happens in the IOCTL that sets the transfer mode and the RW call itself.
Then look at the HW register contents to see if they have been set up similarly to what is done in the bareboard project.
What is the particular error that you are getting on the slave side (change code to print error number, not just "ERROR" string)?
Hope this helps...