ADAR1000 daisy chain works with GUI, but not with Matlab/Arduino SPI commands

Is the same Arduino used in both cases?  And is the connection the same to the P1 connector on the ADAR1000 board?  My first thought was that the Arduino is only setting the bottom two bytes with your writeRead() function and not setting the top byte that has the chip address bits in it, and that is why you are only able to control Chip 0x00.  But if you are using the same Arduino in both cases, this probably is not the cause?

I would start by checking the SPI signals with an oscilloscope, particularly the input data line to make sure you are writing what you think you are writing.  I would start with your first case where it sounds like you only have one eval board connected on the SPI bus.  Make sure both the data is OK, and the SPI signals are basically a square wave.  You don't want to see large overshoots are long RC time constants in either case, which could violate the setup and hold times.  I want to make sure having extra chips on the SPI bus & the interconnecting wires between them isn't adding too much parasitic capacitance and inductance, which would degrade the signal fidelity of the SPI signals.

I am assuming that the Arduino connects directly to the Chip 0x00 board, and then Chip 0x20, 0x40, and 0x60 are connected down the daisy chain line?  A quick check you could do is make the "Chip 0x00" board the "Chip 0x20" board, and vice versa so that the Arduino is first talking to Chip 0x20, then 0x00, 0x40, and finally 0x60.  If you can talk to the new Chip 0x20 and not Chip 0x00, the SPI signal quality is probably degrading as you going down the daisy chain line.

Thanks for your response, and apologies for the late reply due to a holiday.

- The same Arduino is used in both cases, and the top byte seems to be set correctly as the board directly connected to the Arduino will only respond if its corresponding address is used.

- When checking the SPI signals with an oscilloscope, I see square waves with mild overshoots at the edges. More importantly, I notice that even for a single board the SPI commands aren't processed properly sometimes (in most cases the Tx bias current doesn't even start flowing) when I touch the SPI MOSI line with the 100 MHz-rated oscilloscope probe. I've already limited the SPI to the minimum clock speed of 0.25 MHz. Seems indeed that there is a parasitic loading issue in the SPI lines. 

- In the daisy-chained scenario, after some testing it indeed seems like the Arduino can only speak with the board it's directly connected to, when it's connected to the first or the last board in the chain (the only ones with an available P1/P2 header). This seems to support the degrading SPI quality along the path.

- 3 out of my four boards are the 'REV E' version, with an additional pin header P11 to stack the boards and directly connect the SPI traces. Despite the shorter and more direct connection, I could not spot a difference between this connection and the ~7.5cm / 3'' 20-pos ribbon cables I was using before. 

- Since both interconnect methods (headers & ribbon cables) work fine when I feed the SPI commands from the SPD-S board, I'm suspecting the Arduino or the jumper-wire connection to the first PCB is the main deterring factor. I've tried an Arduino Uno instead of a nano: no difference.

Update: Whilst writing this reply I was continuously testing and double-checking the steps. For some reason, the Arduino nano seems to be able to control all 4 boards when it's connected to one of the two center boards via the REV-E P11-header. The SPI_SEL_A of one of the outer boards is used, as it is not available on P11. When it's connected to the first or the last board in the chain, only the directly connected board can be addressed.

While it suddenly seems to work now, I'm not completely convinced yet that it's stable. I'll try a shorter jumper-wire connection from the Arduino tomorrow. Please let me know if you have any other suggestions based on the described results.

Thanks, and best.

Thanks for your response, and apologies for the late reply due to a holiday.

- The same Arduino is used in both cases, and the top byte seems to be set correctly as the board directly connected to the Arduino will only respond if its corresponding address is used.

- When checking the SPI signals with an oscilloscope, I see square waves with mild overshoots at the edges. More importantly, I notice that even for a single board the SPI commands aren't processed properly sometimes (in most cases the Tx bias current doesn't even start flowing) when I touch the SPI MOSI line with the 100 MHz-rated oscilloscope probe. I've already limited the SPI to the minimum clock speed of 0.25 MHz. Seems indeed that there is a parasitic loading issue in the SPI lines. 

- In the daisy-chained scenario, after some testing it indeed seems like the Arduino can only speak with the board it's directly connected to, when it's connected to the first or the last board in the chain (the only ones with an available P1/P2 header). This seems to support the degrading SPI quality along the path.

- 3 out of my four boards are the 'REV E' version, with an additional pin header P11 to stack the boards and directly connect the SPI traces. Despite the shorter and more direct connection, I could not spot a difference between this connection and the ~7.5cm / 3'' 20-pos ribbon cables I was using before. 

- Since both interconnect methods (headers & ribbon cables) work fine when I feed the SPI commands from the SPD-S board, I'm suspecting the Arduino or the jumper-wire connection to the first PCB is the main deterring factor. I've tried an Arduino Uno instead of a nano: no difference.

Update: Whilst writing this reply I was continuously testing and double-checking the steps. For some reason, the Arduino nano seems to be able to control all 4 boards when it's connected to one of the two center boards via the REV-E P11-header. The SPI_SEL_A of one of the outer boards is used, as it is not available on P11. When it's connected to the first or the last board in the chain, only the directly connected board can be addressed.

While it suddenly seems to work now, I'm not completely convinced yet that it's stable. I'll try a shorter jumper-wire connection from the Arduino tomorrow. Please let me know if you have any other suggestions based on the described results.

Thanks, and best.