Daisy chaining w/ drvAsynSPI

[Rea Domitrović via Tech-talk <tech-talk at aps.anl.gov>]

Hi all,

I'm trying to control stepper motors on an STMicroelectronics X-Nucleo IHM02A1 using drvAsynSPI: https://urldefense.us/v3/__https://github.com/kek-acc/drvAsynSPI__;!!G_uCfscf7eWS!fzceelD25OwHKPh5EDRBloYT8LVh145PHpGFx6MCZzT9oMbMT8qktYUw5nBe2RPCrCFsar88g8Ht_PPAn84rEPjrcDUi1g$  and I'm running into a seemingly intractable issue.

So far, what I've been able to deduce from working with the device using my own code: https://urldefense.us/v3/__https://github.com/redomitro/STM32Pi__;!!G_uCfscf7eWS!fzceelD25OwHKPh5EDRBloYT8LVh145PHpGFx6MCZzT9oMbMT8qktYUw5nBe2RPCrCFsar88g8Ht_PPAn84rEPheaRTtJQ$  is that the main problem is in the board itself containing two daisy-chained controllers. Because of the daisy chaining and how SPI works, data needs to be sent by columns, i.e. if we want to send the following: (n.b. device 0 is the device furthest from the host in the wire chain due to how SPI daisy chaining works)

device 0: 0x51 0x00 0x3f 0x80
device 1: 0xd0 0x00 0x00 0xa0

we need to send each column as a transaction, i.e. transpose the matrix:

tx 0: 0x51 0xd0
tx 1: 0x00 0x00
tx 2: 0x3f 0x00
tx 3 0x80 0xa0

I've been able to get the motor to accurately perform test movements using that structure and using a bitmask on output data. However, I want to implement that same capability in EPICS, and this is where the bug appears. Namely, when I send (0xd0, 0xd0), a status request command, both controllers correctly exit the fault status as evidenced by the fault LED extinguishing. When I send (0x21, 0x21) to query for position, the position data comes back correctly interlaced. However, in both situations, the last byte of the response seems to get swallowed - instead of reporting 0xfe03, the controllers report 0xfe00, and if I manage to move the controller with a jog command, the first two bytes of the response (bits 23-16 and 15-8) come back correctly, but the third gets zeroed out for some reason.

On the other hand, sending a jog command with max speed (0x0fffff) gets interpreted, for some reason, without interlacing: ((0x51, 0x00), (0x0f, 0x00), (0xff, 0x00), (0xff, 0x00)) gets interpreted as (0x51, 0x00, 0x0f, 0x00) - on the correct controller every time, but at a very wrong speed. The communication log will be below.

Is controlling daisy chained devices with drvAsynSPI even possible? Has anyone worked with the package before? I'd be very grateful for a second pair of eyes on the problem. My own source code is here: https://urldefense.us/v3/__https://github.com/redomitro/motorSTMicro__;!!G_uCfscf7eWS!fzceelD25OwHKPh5EDRBloYT8LVh145PHpGFx6MCZzT9oMbMT8qktYUw5nBe2RPCrCFsar88g8Ht_PPAn84rEPjGVogRHA$ 

Kind regards,
Rea Domitrović
Institut Ruđer Bošković
Zagreb, Croatia

--- Sample communication output: ---

00 51
2026/07/27 10:56:55.151 asynOctetSyncIO read:

00 00
2026/07/27 10:56:55.152 asynOctetSyncIO wrote:

00 0f
2026/07/27 10:56:55.152 asynOctetSyncIO read:

00 00
2026/07/27 10:56:55.152 asynOctetSyncIO wrote:

00 ff
2026/07/27 10:56:55.153 asynOctetSyncIO read:

00 80
2026/07/27 10:56:55.153 asynOctetSyncIO wrote:

00 ff
2026/07/27 10:56:55.153 asynOctetSyncIO read:

00 80
2026/07/27 10:56:55.154 asynOctetSyncIO wrote:

d0 d0
2026/07/27 10:56:55.154 asynOctetSyncIO read:

fe ff
2026/07/27 10:56:55.154 asynOctetSyncIO wrote:

00 00
2026/07/27 10:56:55.154 asynOctetSyncIO read:

00 00
2026/07/27 10:56:55.155 asynOctetSyncIO wrote:

00 00
2026/07/27 10:56:55.155 asynOctetSyncIO read:

00 00
2026/07/27 10:56:55.155 asynOctetSyncIO wrote:

21 21
2026/07/27 10:56:55.155 asynOctetSyncIO read:

00 02
2026/07/27 10:56:55.156 asynOctetSyncIO wrote:

00 00
2026/07/27 10:56:55.156 asynOctetSyncIO read:

00 34
2026/07/27 10:56:55.156 asynOctetSyncIO wrote:

00 00
2026/07/27 10:56:55.156 asynOctetSyncIO read:

00 00
2026/07/27 10:56:55.157 asynOctetSyncIO wrote:

00 00
2026/07/27 10:56:55.157 asynOctetSyncIO read:

00 00
2026/07/27 10:56:55.167 asynOctetSyncIO wrote:

d0 d0
2026/07/27 10:56:55.167 asynOctetSyncIO read:

fe fe
2026/07/27 10:56:55.168 asynOctetSyncIO wrote:

00 00
2026/07/27 10:56:55.168 asynOctetSyncIO read:

00 00
2026/07/27 10:56:55.168 asynOctetSyncIO wrote:

00 00
2026/07/27 10:56:55.168 asynOctetSyncIO read:

00 00
2026/07/27 10:56:55.168 asynOctetSyncIO wrote:

21 21
2026/07/27 10:56:55.169 asynOctetSyncIO read:

00 02
2026/07/27 10:56:55.169 asynOctetSyncIO wrote:

00 00
2026/07/27 10:56:55.169 asynOctetSyncIO read:

00 59
2026/07/27 10:56:55.169 asynOctetSyncIO wrote:

00 00
2026/07/27 10:56:55.170 asynOctetSyncIO read:

00 00
2026/07/27 10:56:55.170 asynOctetSyncIO wrote:

00 00
2026/07/27 10:56:55.170 asynOctetSyncIO read:

00 00
2026/07/27 10:56:55.180 asynOctetSyncIO wrote: