STM32F427VIT I2S strange desync problem

miavenitoidee123 · ‎2014-07-10

Posted on July 10, 2014 at 11:11

The original post was too long to process during our migration. Please click on the attachment to read the original post.

waclawek.jan · ‎2014-07-10

Posted on July 10, 2014 at 13:02

> After a while (3-12 hours) the I2S transmit DATA pin starts to get desynchronized. I use the oscilloscope to probe the WS pin vs DATA pin.

At this moment, are

- received data as seen on oscilloscope in sync or not?

- received data in the receiver's buffer OK or not?

JW

miavenitoidee123 · ‎2014-07-10

Posted on July 10, 2014 at 13:21

Hi

Sorry for not being so clear about this. There is more about what tests I did until now.

I ignored receive stream for a while now to make sure first the transmit part is working fine. So I filled all the transmission buffer with a dummy value and waited. At the beginning the oscilloscope sees the dummy value in sync with WS clock for a while (few hours) then the dummy value gets shifted. Then I have to reset and this process starts again. If I wait more, the bits shifting occurs more until the data stream is in sync again but channels are switched. The data is never shifted with a small number of bits. I assume there is a constant number 16bit or so. To make sure about this I will update with more info as soon as I catch it.

waclawek.jan · ‎2014-07-10

Posted on July 10, 2014 at 13:50

This is very weird.

To me it sounds as if the DMA misses an update (i.e. the I2S underruns). Have you had a look at SPI->SR after the ''shift'' has happened?

More questions: what is the APB1 clock? Is there any other DMA1/APB1 activity going on?

JW

miavenitoidee123 · ‎2014-07-10

Posted on July 10, 2014 at 14:20

What a coincidence. I just started to realize too that this might be a DMA issue.

I watched the SR value after the ''shift'' but no change. I mention that the SR was watched in the while(1){} loop with printf()so maybe an error interrupt got called and the flag was cleared and I didn't catch the signal. I will recompile my source and make sure I can catch any error interrupt by marking a new variable as true.

The only activity is the DMA for TX and RX for i2s full duplex stream.

APB1 is at 42Mhz

I was checking in the forum

/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Debugging%20DMA%20transfers&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=434

In this thread. This guymight have the same issue as I do

________________

Attachments :

clocks.png : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I0ij&d=%2Fa%2F0X0000000bcx%2FBp_lUWB3D20rzPaRj6vML6SVJ16NGVVtFxC6SJKhHVI&asPdf=false

miavenitoidee123 · ‎2014-07-10

Posted on July 10, 2014 at 16:05

I need to mention some other things that might help to solve this issue or might help others.

I also have my doubts that this might not be a DMA issue.

When I first built this testing prototype I was expected to run the MCU as slave full duplex.

First I hit a wall: when running slave mode the I2S only uses WS for starting the transfer as it states on the errata for all STM32F 407/417/427:

In slave mode, the WS signal level is used only to start the communication. If the I2S (in slave mode) is enabled while the master is already sending the clock and the WS signal level is low (for I2S protocol) or is high (for the LSB or MSB-justified mode), the slave starts communicating data immediately. In this case, the master and slave will be desynchronized throughout the whole communication.

Workaround

The I2S peripheral must be enabled when the external master sets the WS line at:

High level when the I2S protocol is selected

This was solved by pulling up the WS pin and initializing and starting the I2S and DMA, then starting the SRC4392 clock after that.

After that WS was in sync with DATA at each start. But I realized something soon:

When I plugged the laptop's charger into the outlet, the DATA stream got desynchronized (''shifted''). This was because some noise from the mains plug was coupling into the power source of my testing board.

After another tests I realized that DAC was sending some short bursts onto the I2S2_CK pin which made the signal of the pin acting like it was in short-circuit but for a very short period of time. This caused both Transmit and Receive. DATA stream to shift LEFT some random number of bits.

To solve the issue. I run the MCU in master mode this time. The issue disappeared from Transmit stream but not from the Receive stream.

After plugging something into the outlet the receive stream got desync again.

This time MCU was running in Master mode and I2S2_CK was an output and the DAC was still sending bursts into the pin which was still affected even when running as an output.

To solve the issue i installed a opamp buffer to make the pin go one way to the DAC.

After this the problem was solved in master mode full duplex.

This bug is not triggering any errors in the SR var (i just checked now for this).

Now I'm having this issue which shifts to RIGHT a constant number of bits.

As I said earlier this doesn't occur if i run from PLL clock and not the external one.

So that's why I see doubts about the problem being from DMA. This might be a STM32 chip issue.

Let's hope I'm wrong. I'm still wating for the next ''shift'' maybe the SR will be set.

This resulted in stream shif

miavenitoidee123 · ‎2014-07-10

Posted on July 10, 2014 at 16:13

Can someone confirm that I2S transmit or receive on any STM32 device with external master clock (full/half duplex) works for a long term use?

miavenitoidee123 · ‎2014-07-10

Posted on July 10, 2014 at 20:10

Caught a ''shift'' again. All DMA interrupt flags are set. No interrupt has been called. SR var remains with no error flags. I can confirm now that the shift is exactly 16bit in length, everything is rotating from left to right 16bits.

waclawek.jan · ‎2014-07-11

Posted on July 11, 2014 at 14:09

The description you gave in the lengthy post above indicates, that you may have ground and/or pin overload issues. Good common ground is vital if you want to transfer MHz signals between boards. I can envisage problems if the I2S_CK pin ''sees'' spikes (pulses of very short duration). Do you use some form of a breadboard, perhaps? They are known to be prone for developing poor/intermittent connection.

JW

miavenitoidee123 · ‎2014-07-11

Posted on July 11, 2014 at 15:05

The DAC is built on a trough hole board. The MCU is also built on a TH board with SMT to TH adapter. The SRC4392, TCXO and the power sources are built on a breadboard.

At the beginning I was having trouble with the wires between boards they where too noisy. But only the receive stream was jumping like crazy when running full duplex master-transmit mode. I replaced all wires with short coaxial cables grounded on both sides of the boards. Now no troubles at all with receive stream.

I tried to remove any load from the The I2S_CK pin and leave only the TCXO and the scope to monitor the transmit stream with no success.

I also tried to disturb the I2S_CK pin (random short circuit/tie to VDD) to reproduce the tx ''shift'', no success either.

Should I insist on more grounding/isolation? This is not so easy also. I'm not so sure that this will improve.

At the moment I tried full duplex: slave-receive, slave-transmit, master transmit but I missed one.

I'm now trying full duplex master receive and now 8 hours have passed and the ''shift'' didn't occurred. Usually I get to see it after about 3-6 hours. Maybe this is the one. I will give it some more hours.