Issue with I2C2 and SPI2

[ruslanpopov]

I have the same issue on STM32F103 with I2C2 & SPI2.

[Giovanni]

I2C2 and SPI2 use the same DMA channels on the F103, probably this is your problem.

Giovanni

[ruslanpopov]

The issue we have is that when you switch off SPI and switch on I2C the later doesn't work properly. To deal with the problem we decided to modify the driver and use IRQs instead of DMA.

Can anyone explain what to do to use IRQs instead of DMA. It is not clear for me.

[Giovanni]

The current driver can only work in DMA mode, it would require changes in oder to work without DMA, it is what wbober decided to do but I don't have any update about this.

Giovanni

[ruslanpopov]

As I see in this code I2C2 uses DMA 4&5 channels.:

Code: Select all

#define STM32_HAS_I2C2 TRUE
#define STM32_I2C2_RX_DMA_MSK (STM32_DMA_STREAM_ID_MSK(1, 5))
#define STM32_I2C2_RX_DMA_CHN 0x00000000
#define STM32_I2C2_TX_DMA_MSK (STM32_DMA_STREAM_ID_MSK(1, 4))
#define STM32_I2C2_TX_DMA_CHN 0x00000000

And here here you may see, that SPI2 uses the same DMA channels:

Code: Select all

#define STM32_HAS_SPI2 TRUE
#define STM32_SPI2_RX_DMA_MSK STM32_DMA_STREAM_ID_MSK(1, 4)
#define STM32_SPI2_RX_DMA_CHN 0x00000000
#define STM32_SPI2_TX_DMA_MSK STM32_DMA_STREAM_ID_MSK(1, 5)
#define STM32_SPI2_TX_DMA_CHN 0x00000000

But in my case I do not use SPI1. Can I remap SPI2 to use DMA channels of SPI1?

[Giovanni]

No,

The channels assignment is fixed in the STM32 (except F2 and F4 that have a channels remapping feature).

Could you just use SPI1 instead?

Giovanni

[ruslanpopov]

Unfortunately, I can use only SPI2 at this moment. I have a GPIO expander on I2C2 and microSD on SPI2. I need to write a data from GPIO to microSD periodically. I'm ready to write some code for ChibiOS but need some guidance.

[Giovanni]

An alternate solution could be to use a SW I2C implementation, it is not very different in efficiency compared to an ISR-driven driver.

I am thinking to add a default SW I2C implementation for fallback in 3.0. The (old) I2C on the STM32 is just too troublesome.

Giovanni

[colin]

Interesting idea to add a software (bit-banged) I2C driver... In fact you could also implement software SPI and even SERIAL drivers which would (a) allow new platforms to get Hello World running before a custom HAL serial driver is written and more importantly having software I2C/SPI/serial drivers would allow adding extra communication ports beyond what the hardware peripherals support, or when there is a conflict like this DMA channel issue. Not too bad for master side. And the beauty is that user code would just use the HAL interface which would be abstracted from whether it's a h hardware or software implementation of the driver.

[Giovanni]

Yes, it is feasible for synchronous protocols, the RT counter in 3.0 could be used for reliable timings. Preemption would create problems in UART simulation unless you do everything with interrupts disabled.

I2C and SPI should work perfectly (excluding callbacks).

Giovanni