I2S problems - CPU stops, halts and other strange things

[king2]

I use I2S driver in my app (STM32F429), RX master, SPI3, (IAR compiler, J-Link Pro probe with SWD).
When I start DMA transfer, strange things happens.
IAR stops CPU as it was breakpoint, but with no real breakpoint, at random address (sometimes 0, sometimes 0x8xxxxxxx or 0x4xxxxxxx...), with stack pointer set to 0x0000xxxx address. Sometimes IAR just losts CPU with error, CPU cannot be halted, cannot read R15 or something like this.
Another strange thing I see - after this happens, registers values can be wrong, i.e. S0PAR=0xA0003C0C, but PAR inside this register=0x40003C0C. Looks like broken connection between J-Link and CPU... or CPU in wrong mode.

I have checked values in DMA registers before start of transfers, and it looks like right values - address of buffer and periphery, size of buffer and DMA mode.

If I comment line i2sp->spi->I2SCFGR |= SPI_I2SCFGR_I2SE; - DMA not works but ChibiOS runs fine.

Any ideas? What it can be?..

[Giovanni]

Probably there is an overflow somewhere: DMA or stack.

Giovanni

[king2]

I have checked variables that placed after the buffer, and found right values, so it is not DMA overflow.
I have CH_DBG_ENABLE_STACK_CHECK set to TRUE, so I think it is not stack overflow?

How to check this?

[Giovanni]

Stack check is not infallible, it is only checked at context switch time, the overflow could happen for other reasons.

Not sure how to proceed, could you isolate the I2S code from the rest? try to understand if it is sufficient to trigger the problem.

Giovanni

[king2]

I have tried to check when it halts, and found.
This breakpoint runs fine till I2S starts DMA transfer.
Next task switching just before it will crash: http://king2.net/files/screen-before-halt.png
As I understand, next asm instruction should store register SP into memory at address 0x20000C8F+12 = 0x20000D04.
When I press F11 (go next), it halts and after I see control back I see following: http://king2.net/files/screen-after-halt.png

I cannot get understand what is going on...

update: I made test firmware and have minimized everything. Still halts, but not exactly at point on screenshot.
update2: I have attached my test app (without ChibiOS, got from ChibiOS_16.1.2.zip). It fails in some time after DMA was set to run (in this case it stops at unhandled exception).

[Giovanni]

I don't see anything obviously wrong with the code, it is very similar to the I2S demo.

From you screenshot it appears to fail during context switch, this means that there is memory corruption. Could you try with GCC and see if you get the same result? this would tell if it is compiler-related.

Giovanni

[king2]

I have tested it again and compared to previous version when it worked. I have found that even if I use I2S3 CPU halts where I have not set I2S2 pins in board.h.

If I set I2S pins (PB12, PB13 and PB15) as alternate with AF=5 - everything works ok (no actual signal on I2S2 pins, but I can see transfer on I2S3 pins - PC10, PC12, PA15 in my case).

DMA sets in both cases to 0x40003C0C - it is SPI3_DR.

I cannot understand this.. will continue testing..

update: I have found root of this problem. It is PB4, which is also NJTRST. I'm using SWD debug, so normally J-Link should not touch this line, but... when I enable PB4 as output, DMA brokes debugging. I have enabled this pin in other version of firmware (CMSIS_OS one) - and everything work normally with its DMA and I2S3..

[king2]

At finish all of this, I cutted link on PCB from CPU to JTAG NJRST, and now nothing halts.
I think it was problem with Segger's J-Link Pro, or its firmware.

[Giovanni]

Weird, try a cheap ST-Link, IAR can use it.

Giovanni