Extra Byte in SPI read action

I like to communicate with an AD7730 (Bridge Transducer) over SPI with FEZ and Tinyclr OS.
What I find is that the data in the read byte array have an additional byte in front. So if the device send 3 bytes I have to clock out 5 bytes (1.st byte is only register address). If I look at the logic analyser, I can not see this addition byte. If have tested different SPI-modes, FEZ boards andvchips, but nothing will help.
Some ideas?
PS.: I like to add a screenshot, but don’t know how.

Can’t recall them now but there are 2 different methods to transfer data over SPI, one consecutive and one full duplex. Do you understand the difference?

Welcome to the community

Thanks for the reply. There several circumstances which make me believe that SPI protocol is not the issue: 1) The AD7730 is a full duplex device.
2)Long time ago I operated the device with a FEZ Panda II. There I used a similar code (with full duplex transfer) and it works fine.
3) Looking at the logic analyser all works fine. The problem is just that the content of the array which is filled by the SPI read command has an additional byte in front. So to obtain the full answer of the device it is necessary to clock for one more byte.
4) Trying to use sequential mode was not successful.
I think an image with logic analyser and memory map would be helpful, but how to send?

Show me this line please

            m_SpiDevice.TransferFullDuplex(m_ByteArrayWrite, 0, 5, m_ByteArrayRead, 0, 5);

Meanwhile I can localize the fault: It happens only if a write command proceed the read and the extra byte is identical with the first byte of the write command.

The line of code you shared will “swap” 5 bytes between the master and salve. The first byte swapped will return garbage typically from the salve since the save have not seen the first byte yet. The second byte swapped is usually a response to the first byte sent… and so on.

There is NO write and read in SPI. You are ALWAYS swapping bytes with every single transaction. If you keep this in mind then you will spot the error.

You are right. There is no consecutive write and read action in SPI. In my case with the AD7730 I “write” some values into a register. This is done by a real SPI.write command. After this I want to test if the transmitted values are in place. So I make a “read” command with a preceding byte indicating what register I want to read. Following further byte to swap the register content. And You are also right that the first byte has no meaning because it gives the slave only the information what he should do next. So the second byte should be the first byte with the desired information. But in my case it is simply the the first byte of the preceding “write” command and after this the content of the register is swapped to the “read-array”. Again: looking on the logic analyser, this byte is not transferred over the lines!

While there maybe a bug, we use SPI regularly without issues. Anyway, TinyCLR 2.0 is changing it all. If you have a commercial need for a business then please request to join our insider program to learn about what is happening behind the scenes.

Ok. I will help myself by simply ignoring this byte and clock an additional byte. May someone else with a similar issue not be so confused as I and lost a lot off time.