I think SPISlave has a couple of problems, they mainly seem to revolve around SPISlave.receive() not telling you when there is a byte available. The first of these issues is easy to create. If you call SPISlave.reply() multiple times the receive() call fails to tell you there is a byte available until sufficient bytes have been sent to cover the extra reply() calls. It's possible to work around this problem by counting ins and outs, but not ideal. The second problem is more of an issue. If you send bytes quickly the Slave will fail to notify of a received byte that is has received, at this time the Master does not get the last reply() value. But the slave did receive the byte because if you do an extra read() call it's there. I've written a couple of simple test programs that can be run on a pair of mbeds that demonstrate the issues and allow you to play around them. The idea is the master sends an incrementing number on each transmission and the slave simply echos it back. Thus the write() should always return the value being sent minus one. The only way to see the missed receive is to run the continuous mode on the master, it'll generally fail within 10-20 transmissions. Do an I (in) on the slave and you'll get the byte. I did wonder if the failure is because the slave hadn't primed the system with a reply() but when stopping the echo the receive() does report correctly the next time a byte is sent. Master Program can be found as http://mbed.org/users/picnic/programs/SSM/lwhxtc Slave Program can be found as http://mbed.org/users/picnic/programs/SSS/lwi182