Problems with SPI2 slave Mode ( STM32F103VE )

[hbastian]

Posted on June 08, 2010 at 09:27

Problems with SPI2 slave Mode ( STM32F103VE )

[Nano1]

Posted on May 17, 2011 at 13:54

Hello chikos,

I want to reply your posting because the described problem is actually my problem. bastian.henrik only forwarded my description into this forum.

Is the skipped byte the first one or the last one (or somewhere in the middle)?

 

It is anywhere in the middle. Not on a constant place.

You said that communication is protected by Checksum, do you mean you are using the SPI CRC mode ? In this case, make sure that the number of data passed to DMA is = (Total number of DATA + 1)

 

It is anywhere in the middle. Not on a constant place.

It seems interesting when you say that using Interrupt instead of DMA the error disappear... In this case, I would rather think about a timing error relative to the instant you enable your DMA and your SPI request...

 

Since SPI2 is slave, you should prepare data before master request it...

 

The data are prepared completely before the master's request.

So try to:

 

  - Enable DMA and DMA request before enabling SPI

I tried this some weeks ago too. Same result.

But in my opinion there is a recommendation to handle this in the opposite way: First enabling SPI, then DMA. (I think I found this recommendation in this forum.) And in the FWLib example code is enabled SPI at first too.

  - Insert a delay between Slave enabling and master enabling.

Slave's DMA and SPI are enabled a long time before the master's request. I'm shure.

One other point: make sure that the CPOL and CPHASE values you are using are compatible with the default state of your SPI pins (ie. if CPOL = 0 and CPHASE = 0 then you should have SPI_SCK pin pulled down in steady state, but if CPOL = 1 then you should pull up your SPI_SCK pin...).

 

I don't believe that this can be the reason. If there is a problem with the clock it should affect the receiving of data too, shouldn't it?

Nevertheless I will try it. I will post the result later.

By the way, we use mode 1, that is CPOL = 0 and CPHA = 1. So I have to pull down SPI_SCK pin. Correct?

I think that the first point is the more likely to be the root of your issue...

I think the same.

Another point: At first I thought a parasitic DMA request is the reason. But 2 weeks ago we discovered

http://www.st.com/stonline/products/literature/es/14732.pdf

. See chapter 2.15 Parasitic TXE generation in SPI2/I2S2 slave mode + 16-bit data frame mode! Except for using 8-bit data frame mode (instead of 16-bit) these are exactly the same conditions like used by us. And, a parasitic TXE generation would affect the same behavior like a parasitic DMA request. (Only the disappearing of the error when I use interrupt instead of DMA objects to this. But this could be caused by another timing.)

Is it possible that the data loss can occur in 8-bit data frame mode too?

Thanks,

Norbert

[chikos332]

Posted on May 17, 2011 at 13:54

Hi Henry,

Is the skipped byte the first one or the last one (or somewhere in the middle)?

You said that communication is protected by Checksum, do you mean you are using the SPI CRC mode ? In this case, make sure that the number of data passed to DMA is = (Total number of DATA + 1)

It seems interesting when you say that using Interrupt instead of DMA the error disappear... In this case, I would rather think about a timing error relative to the instant you enable your DMA and your SPI request...

Since SPI2 is slave, you should prepare data before master request it...

So try to:

  - Enable DMA and DMA request before enabling SPI

  - Insert a delay between Slave enabling and master enabling.

One other point: make sure that the CPOL and CPHASE values you are using are compatible with the default state of your SPI pins (ie. if CPOL = 0 and CPHASE = 0 then you should have SPI_SCK pin pulled down in steady state, but if CPOL = 1 then you should pull up your SPI_SCK pin...).

I think that the first point is the more likely to be the root of your issue...

Good luck :)

[Nano1]

Posted on May 17, 2011 at 13:54

Hello,

... especially when the position is completely random...

It seems to be so.

...you can test by leaving only TX direction working

I will do it.

... or by using SPI3 instead of SPI2

That requires bigger efforts. Modification of hardware and software would take some time.

Some weeks ago I used SPI1 instead of SPI2 for a test. Thus, the error disappeared. But I can't interchange the SPIs permanently. This would require a bigger redesign of hardware and software.

Do you expect further conclusions by using SPI3 instead of SPI2?

or using the 8-bit mode (be careful about MSB/LSB order) ...

Oh, it seems there is a misunderstanding. We use the 8-bit mode, not the 16-bit mode. (Sorry, I didn't explain it very clearly.)

The errata sheet says that the data loss can occur only in 16-bit data frame mode, not in 8-bit mode. And that's my question: Is it really so? All other conditions are the same like described, but we have the error in 8-bit mode.

(I can't try the 16-bit mode because of the 8051 is not able to operate in 16-bit mode.)

By the way, what are the used frequencies in your application?

- SPI Master communication frequency: about 1.5 MHz

- STM32 SYSCLK frequency: 72 MHz

- APB1 prescaler (PCLK1 frequency): RCC_PCLK1Config(RCC_HCLK_Div4);

Don't forget that the max freq for the SPI slave is PCLK1_freq/2

The 8051 (SPI master) is relative slowly, so this shouldn't be a problem.

... and that PCLK1_freq = SYSCLK_freq/2 in best case....

What does it mean? - I just don't remember why we choosed prescaler 4. Do you mean prescaler 2 would be better?

[chikos332]

Posted on May 17, 2011 at 13:54

Hi,

If the error occurs anywhere in the middle it is more likely to be parasitic, especially when the position is completely random... so in this case we can discard the possibilities that I suggested.

Yes, reading the ErrataSheet is seems to be possible to have this issue on TXE even in DMA mode (since DMA is only sensitive to TXE requests just like the software)...you can test by leaving only TX direction working or by using SPI3 instead of SPI2 or using the 8-bit mode (be careful about MSB/LSB order) ...

By the way, what are the used frequencies in your application?

You need to monitor the following parameters:

  - SPI Master communication frequency

  - STM32 SYSCLK frequency

  - APB1 prescaler (PCLK1 frequency)

Don't forget that the max freq for the SPI slave is PCLK1_freq/2 and that PCLK1_freq = SYSCLK_freq/2 in best case....

We'll wait for more test results from your side :)

[chikos332]

Posted on May 17, 2011 at 13:54

Hi,

That becomes a little confusing, if you are using 8-bit mode and DMA you are not really in the conditions of the errata sheet...

Yes I would advise, if possible, to user prescaler 2 for the PCLK1 instead of 4, that will surely increase the ability of CPU to access the SPI register at time.

I think that even if your 8051 cannot work in 16bit mode you can configure your slave in 16-bit mode if the number of data is always even (that's not a clean way but it would be a good workarround, I've never tried such configuration).

Cheers.

[Nano1]

Posted on May 17, 2011 at 13:54

Hello,

That becomes a little confusing, if you are using 8-bit mode and DMA you are not really in the conditions of the errata sheet...

All other conditions are the same. I wrote: ''Except for using 8-bit data frame mode (instead of 16-bit) these are exactly the same conditions like used by us.''

It is confusing for me that we have the same data loss in 8-bit mode.

Yes I would advise, if possible, to user prescaler 2 for the PCLK1 instead of 4, that will surely increase the ability of CPU to access the SPI register at time.

 

It sounds logical. So I will try it and post the result.

I think that even if your 8051 cannot work in 16bit mode you can configure your slave in 16-bit mode if the number of data is always even

Oh, you are right. I didn't consider so far to use the 16-bit mode because the master sends single bytes. But it should work in 16-bit mode too. (I have to receive 184 byte - an even number.)

(that's not a clean way but it would be a good workarround, I've never tried such configuration).

I will try it. Then we will know if we have the data loss in 16-bit mode too. It could be a good workarround.

But I can't execute the tests immediately. I will post the results next Tuesday or Wednesday.

So long!

[dimmatx]

Posted on May 17, 2011 at 13:54

There were same problems.

Has solved thus

Has installed the protocol:

Phase 0, polarity 0

[Nano1]

Posted on May 17, 2011 at 13:54

Hello,

the tests took a bit longer time. Many changes forced further effects. But here are the results:

I used a CPU which generated transmit errors in about 25% of all transfers.

1) Pull down SPI_SCK

Pull down resistance 10 kOhm at SPI_SCK pin => Same behaviour (furthermore 25% faulty transfers)

Additionally test with pull up => Same behaviour (furthermore 25% faulty transfers)

2) Leaving only TX direction working

I wanted to test it. But then I remembered: I will not get information from the 8051 if it detected a checksum error. So I didn't test it.

3) APB1 prescaler 2 instead of 4

I doubled the PCLK1 frequency by changing the APB1 prescaler from 4 to 2. (Additionaly I had to change the TIM2, TIM3 and TIM4 prescaler and/or reload values.)

I got a strange result: The number of faulty transfers increased to about 50%. Why this???

4) 16-bit data frame format instead of 8-bit

I changed the data frame format for SPI2, DMA1 channel 4 and 5 from 8-bit to 16-bit. (Additionally I had to swap the data words.)

Result: Inexplicably the SPI2 error Flags SPI_I2S_FLAG_OVR and SPI_I2S_FLAG_BSY were set at the end of the transfer. But the checksum was o.k. And the number of faulty transfers didn't change significant - it was about 30%.

Any new ideas??

P.S.: Just now I saw a mistake in the thread's title: We use a STM32F103VE, not a STM32F102VE ! Is it possible to change the title?

[Nano1]

Posted on May 17, 2011 at 13:54

Problem solved

Hello Dmitry,

Thank you for your reply. Maybe CPOL = 0 and CPHA = 0 was a solution for you. But I can't change the software of the SPI master.

Nevertheless I got the solution from ST's support departement:

''Following our design team investigation the problem is the same as described in errata sheet for 16-bit mode only. It’s actually the first time seen on 8-bit mode.

 

The problem is solved on revision Y of the STM32 chip. Could you please ask your distributor to get samples of this revision for your tests?''

 

It took a long time and a lot of support. But now we know: Revision Z can have the SPI slave problem. We need micros of the revision Y. All the Y micros we got from ST were okay as yet.

:)