L6474 only answers SPI command by sending the command back after 1 Byte delay

[eg7963]

I'm controlling a L6474PD Stepper motor driver withan STM32F338 mcu. It is not a demo PCB but PCB made for our targeted product.

I manage to control the motor with PWM and DIR pins, and send Disable and Enable SPI Commands that work ( basically all commands not requiering feedback ar ok).

 

However , trying to send a GetParam or GetStatus command over the MOSI line only returns the sent bytes over the MISO.

I first thougth that it was a short between the 2 lines, but the strange thing is that the feed back comes with 1 byte delay (check with the Scope), which means the drivers acts like it saves the received command, and send it back on the next incoming byte over SPI bus.

 

For example if i send

D0h, 00h, 00h ( Get Status + 2 x Nops)

in the RX buffer I receive

00h, D0h, 00h

as answer , and that for evey byte sent.

 

i tried to send

D0h, 55h, 00h ( Get Status + Random byte + NOP )

i received

00h, D0h, 55h

 

As i said , the signals and the 1 byte delay are also visble on the scope

 

For convenience, i used the HAL library ( no DMA, no IT ) HAL_SPI_TransmitReceive, 1,2 Mbps, Pol High, 2 Edge, 8 bits MSB, and soft CS, TI mode disabled as in the L6474 examples available for IHM01A1 boards, CS stays LOW for the whole 1, 2 , 3 or 4 bytes length of a command and is hgih otherwise

 

As this behaviour is not expected and quite strange, i was wondering if anybody already had such case.

 

Thanks

[eg7963]

Ok i figured it out myself through the application note AN4290 and by reading more carefully the datasheet :

"After each byte transmission, the CS input must be raised and be kept high for at least tdisCS

in order to allow the device to decode the received command and put the return value into

the shift register."

But the Daisychain diagram is kind of misleading as it shows the CS signal down for the whole command + bytes transmission.

I'll restest the programm with the changes.

[Dario CUCCHI]

Hi @eg7963​ ,

Good you have fixed the problem ! That’s exactly the correct way to manage the communication.

Let me add just one remark.

“Daisychain diagram is kind of misleading as it shows the CS signal down for the whole command + bytes transmission�?.

It is not about command + byte transmission, it is about the number of devices in the daisy chain.

In fact, the CS stays low for a number of bytes equivalent to the number of the devices in the chain.

For example, if you have 4 devices chained, the CS stays low until the 4th byte is transmitted (32 clock pulses)

All the data are shifted along the chain (what you saw at the beginning) and when each device has its own byte the CS is raised and the byte is processed by the four devices at the same time.

In this way, you can synchronize commands to be executed at the same time on multiple devices (see Figure 10 in the AN).

In your case you have just one device in the chain, so the CS must be raised at each byte to be processed.

I hope this explanation can help to clarify how the communication is managed in the L6474.

[eg7963]

The application note AN4290 shows a image of the buffer a bit more detailled.

After a few thoughts i'm getting the bigger picture of the daisy chaining and the shift register usage.

I'm just not used to daisy chain the SPI devices but that all makes sens now.:thumbs_up:

[Tesla DeLorean]

Or that the bus is symmetrical? command clocks in, additional clocks to get the response/data related back?

[eg7963]

The Nop commands are actually inteded in that purpose ( clocking in to get the data out).

The CS raise after each byte transmission has solved the problem i had.

Apperently the L6474 needs it to process the byte in the shift register and determine if its a command or data.

Withouth the CS , the input data stays in the shift register , and is clocked out when the next clock cycles come.

Ironically, i was doing CS raise after each bytes initally and decided to make it command wide as i didn't notice anything in the datasheet that prevented to do so at that time.

:grimacing_face: