Whether flow control byte is needed in the SPI frame for STM32F407？

[JieShen_Jason]

Hi，

There is a STM32F407 on my board to configure and control the optical module. Also, STM32F407 use SPI to interface with CPU. STM32F407 work as SPI slave mode, and CPU work as master mode. Some protocol require one flow control byte in SPI timing, such as OIF protocol. My understanding is :

For read operation. After slave receive the operation code and address, slave need time to prepare data according to address then put the data into TX_Buffer. This all will be finished in the one clock period as below red mark shown. If slave can't finish the job in time, slave must inform to host through flow control byte .

My question is whether flow control byte is needed in the SPI frame for STM32F407？or it can mitigate this issue through reducing the SCK frequency, not through flow control byte?

Thanks in advance!

Best regards!

Jason

[Andrew Neil]

---

@JieShen_Jason wrote:

There is a STM32F407 on my board

---

What board is it? Please give details - see: How to write your question to maximize your chances to find a solution

In particular:

---

@JieShen_Jason wrote:

optical module.

---

What optical module?

---

@JieShen_Jason wrote:

STM32F407 use SPI to interface with CPU.

---

What CPU?

---

@JieShen_Jason wrote:

My question is whether flow control byte is needed in the SPI frame for STM32F407？

---

Whether it's needed or not has nothing to do with the STM32.

If the STM32 is communicating with a device which uses it, then the STM32 will have to handle it!

[TDK]

> STM32F407 on my board to configure and control the optical module

So STM32 is master here?

> STM32F407 work as SPI slave mode

???

A flow control byte is not standard in SPI communication. You'll have to work out what you're talking to and whether or not that device needs it. Your architecture doesn't quite make sense.

CPU -> STM32 -> Optical Module

SPI can only have master and slave, not a chain of 3 devices.

[JieShen_Jason]

Hi，

Thanks for your response in time!

Sorry that I confuse you. I only care about SPI interface between STM32F407 and CPU, and just mention the optical module. You can ignore optical module. Yes, for SPI interface between STM32F407 and CPU, STM32F407 work as slave mode and CPU work as master mode. My concern is that whether STM32F407 could handle data during one clock period? If not, flow control byte is needed or reduce the frequency of SCK for mitigating it? 
The format of flow  control byte is below:

0x00： ACK， slave could handle this access, and next byte transmitted is data

0xFF:  NACK, slave couldn't handle current access, and next byte transmitted is flow  control byte too.

If CPU support flow control function and support it into the SPI  timing, STM32F407 also must support flow control function. And vice versa.

Thanks in advance!

Best regards!

Jason

[Andrew Neil]

---

@JieShen_Jason wrote:

I only care about SPI interface between STM32F407 and CPU

---

Still no idea what this mystery "CPU" is

---

@JieShen_Jason wrote:

My concern is that whether STM32F407 could handle data during one clock period?

---

That's going to depend very much on your system - impossible to give a general answer.

I'd say the safest way forward is to assume that it won't, and design-in support for this "flow control".

Then you won't get any nasty surprises...

[JieShen_Jason]

Hi

Thanks! The mystery "CPU" is Intel Xeon D1627 :). 

SPI of MCU is driven by software, and it don't like some peripheral device which use hardware circuit to drive SPI interface. So, I will add this flow control byte firstly according to your suggestion.

Thanks in advance!

Best regards!

Jason

[Ozone]

> Yes, for SPI interface between STM32F407 and CPU, STM32F407 work as slave mode and CPU work as master mode. My concern is that whether STM32F407 could handle data during one clock period? If not, flow control byte is needed or reduce the frequency of SCK for mitigating it? 

First, the term "flow control" is a bit misleading, because it usually implies additional hardware signals. And this is not the case with SPI.

And I'm not sure what you mean with "clock period".
Most probably not a single SPI clock cycle, the MCU/CPU never sees that.
Received data are only visible after the scheduled reception. With "scheduled reception" means the configured size, which is either 8, 16 or 24 bits for the F407 (AFAIK). Only then the received value is transferred from the SPI hardware to the Rx register.

Looking at the transfer diagram in your initial post, I think the F407 cannot do that.
You know the command and 24-bit address only after the MCU has received them. The F407 can only satisfy the request after it decoded it, and fetched the values.
If the other side (CPU) immediately continues to clock in/out bytes at that point, there is no time to do that. Most probably the MCU has not even "seen" the received bytes yet.

Some for of "protocol flow control" is necessary.

[Andrew Neil]

---

@Ozone wrote:

First, the term "flow control" is a bit misleading, because it usually implies additional hardware signals. .

---

Not at all; eg, so-called "software" flow control is well-known on RS232 - using XON/XOFF.

aka "in-band" signalling.

[JieShen_Jason]

Hi,

This kind of flow control  byte in the SPI frame is defined by OIF-CEI protocol, that server for interfacing with MCU in the optical module. It is in-band flow control means  if MCU(work as slave mode) couldn't finish data process in one SCK cycle after it receive command and address byte. Before that,  slave MCU need to agree with CPU or main-control unit how to interpret this byte, as below word shown:

0x00： ACK， slave MCU could handle this access, and next byte transmitted is data

0xFF:  NACK, slave MCU couldn't handle current access, and next byte transmitted is flow  control byte too.

 I think speed of Bus is fast than SCK frequency. So, could reducing the frequency of SCK mitigate this issue?

Thanks in advance!

Best regards!

Jason

[Andrew Neil]

---

@JieShen_Jason wrote:

 I think speed of Bus is fast than SCK frequency. So, could reducing the frequency of SCK mitigate this issue?

---

Again, you have this "flow control" mechanism defined - why not just use it?