SPI causing crash on STM32F207 / STM3220G

[infoinfo993]

Posted on November 29, 2011 at 21:07

Hi folks,

I have an odd problem I've discovered using an STM3320G eval board. I'm using SPI2 connected to PI1/PI2/PI3, and using PI0 as a GPIO-controlled NSS signal. The problem comes in when I transfer a lot of data over this port. It's connected to a 25AA1024 SPI EEPROM, which I have connected to a daughterboard that sits on the STM3320G's expansion connectors. When I write a lot of data to the EEPROM, the CPU will crash and my JTAG debugger will get very confused - to the point where I can't get any meaningful information about the crash.As soon as I connected a logic analyzer lead to the MOSI pin, the problem went away! I'm guessing the additional capacitance was enough to slow the edges of the signal, preventing it from crosstalking with... something.In further experimentation, I found the following:

• SPI clock 7.5MHz, pins set to 25MHz mode, no logic analyzer = crash
• SPI clock 7.5MHz, 25MHz mode, logic analyzer connected to MOSI = no crash
• SPI clock 7.5MHz, 25MHz mode, logic analyzer connected to MOSI and SCK = crash
• SPI clock 1.875MHz, 25MHZ mode, no logic analyzer = crash
• SPI clock 1.875MHz, 25MHz mode, logic analyzer connected to MOSI = no crash
• SPI clock 1.875MHz, 25MHz mode, logic analyzer connected to MOSI and SCK = no crash
• SPI clock 117kHz, pins set to 25MHz mode, no logic analyzer = crash
• SPI clock 1.875MHz, 2MHz mode, no logic analyzer = no crash

So it definitely seems related to crosstalk. Anything that slows the signal edges seems to fix the problem, although connecting the logic analyzer to both SCK and MOSI also causes a crash at higher clock speeds.

By running the SPI clock below 2MHz and configuring the pins to 2MHz mode, I can prevent the problem from happening, but I'm really interested to know what could cause this to happen? What signal would be getting affected by MOSI enough to cause the CPU to crash? Without enough knowledge of the STM32F207 internals and the board layout of the STM3220G, it's hard for me to figure this out.Thanks in advance for any insight you can provide! #stm3320g-spi-stm32f207

[aqueisser]

Posted on November 30, 2011 at 20:55

We've found the SPI signals on the ST eval boards to be very messy. Usually the clock signal is riding on the other lines and messes things up, going to a custom board really helped us. Some more things you can try:

- Hook up a scope and see what the signal quality is, with and without the logic analyzer.- Try to find out whether the data lines cause additional clock edges or vice-versa. Probably both is happening but if you can manage to send and receive a bunch of 0x00 or 0xFF values you may be able to narrow down the problem- Add some termination to your signals - I'm no EE but you can try adding some resistors at either end of the connection.