Master Slave sync queston

[Greybeard]

I have two nucleo boards communicating over SPI.  No Interrupts; No DMA ;   Using HAL TransmitReceive(..)   Chip Select set by software.  Simple  8 char ASCII Transfer.  Everything Works....almost.  I am using a logic analyzer to monitor the interaction. 

When I start both the Master before the Slave,  every thing works.

When I start the Master After the Slave, No Data Transfer takes place.

Is this normal behavior??

How can I keep the two units in sync if the Master starts after the Slave???

Any suggestions??

[David Littell]

SPI was never intended to be a general networking technology.  To bludgeon it into submission requires (quite) a bit more coordination protocol design and implementation beyond what the HAL provides.

[SofLit]

Hello,

---

When I start the Master After the Slave, No Data Transfer takes place.

---

It depends on how do you mean by "start the Master After the Slave".

The clock is generated by the master. If at that time (the master is at reset state) there is no clock seen by the slave -> no data transmitted.

[Greybeard]

Starting the master means beginning a new Debug session. Download code and running from reset

The master Pseudo Code is

Initialize stuff

While 1

    Fill the TX buffer and Zero the RX Buffer

   Reset CS

    Short wait(50us) to give the slave time to respond

   TransmitReceive(..)

   Set CS

   Long wait(1000ms)

I Thought that handling the CS should cause the two units to sync.

Slave pseudo code

Initialize stuff

While 1

     Fill Transmit buffer

    Zero Receive buffer

   Wait for CS to go low

        TransmitReceive(...)

   Wait for 500 ms

Code Attached

[Greybeard]

Thanks.  I am just getting started with SPI and trying to understand a very simple exchange between two units.  Lack of ability for the slave to sync with the master, if the master resets. is something to note and attempt to understand. 

[Andrew Neil]

There shouldn't be any problem to sync slave to master!

Chip Select marks the start & end of each transfer;

Clock clocks the bits.

What do you mean by, "No Data Transfer takes place" ?

Is there activity on the wires?

[David Littell]

OK, so the first thing that jumps out is the 50 uSec delay after the Master asserts CS.  The Slave is (supposed to be) already waiting (because you started it before the Master, right?) for CS to be asserted.  How do you know 50 uSec is enough for the Slave to plow through the HAL's ..._TransmitReceive() and actually be ready to extract the data from the SPI hardware?  See the race?

And where actually is this 50 uSec delay in the Master code?

And what's that extra HAL_SPI_Receive() doing in the Slave?

And the return codes from all HAL_...() calls should always be checked and handled.

[Greybeard]

I started with a 1ms HAL_Delay and worked backward with timer interrupts until it stopped working.  Then added a bit more.  The problem is the slave had a different clock speed that the master.

fat finger.  I took it out and behavior didn't change.

I stopped debugging and downloaded the release code to both units. I can get stable exchange as long as I start the slave AFTER I start the master.  Once running I took the following screen test and took screens shots from the logic analyzer.   

With both master and slave running and the logic analyzer displaying the expected data, I reset the master and observed the results. The images uploaded show the results. After the master reset,  the MISO data from the slave is not as it should be and does not recover until I reset the slave.  By reset, i mean push the little black button on the Nucleo board.  Once recovered things appear work normally until I reset the master (the little black button) and the problem re-occurs. 

It appears that something is happening during the master initialization process that affects SPI lines which in turn affects the slave.  I don't know how and haven't the foggiest idea where to start looking to discover the reason.

Easy solutions:  Common power supply and common reset lines should take care of about 90% of the problems.

I would be nice to know how the master can detect out-of-sync behavior of the slave and attempt to correct the problem.