1. Introduction
In discussions with developers using the Xianji RT-Thread BSP, it was found that the SPI device driver occasionally encounters illegal access exceptions in polling mode (as shown in the figure).
Problem reproduction scenario::
1. The developer only needs to transmit a single message once but did not explicitly initialize the struct rt_spi_message’s next pointer.2. Since next is not assigned to RT_NULL, it triggers illegal memory access during chained transmission (next points to an uncontrollable address). Fix: Explicitly set next to NULL, and the exception disappears.
This article will delve into the RT-Thread SPI driver’s chained transmission mechanism and explore the adaptation characteristics and advantages of the Xianji BSP for the RT-Thread SPI interface.
If you are interested in articles related to Xianji RT-Thread, you can check out the series of articles on this public account: “Xianji RT-Thread-BSP Development and Application Series Articles“
2. Analysis of RT-Thread SPI Chained Transmission Mechanism
1. Core data structure: struct rt_spi_message
RT-Thread describes SPI transmission operations through struct rt_spi_message, supporting single or multiple message chained transmissions.
Key member next1). If it is NULL, it indicates that the current message is the last one in the chained transmission.2). If not NULL, ensure that the next pointing to rt_spi_message has been correctly initialized.3). The consequence of not initializing next during chained transmission is that the driver will attempt to access an invalid address pointed to by next, leading to illegal access exceptions.
In the official RT-Thread wiki example, it can be seen that when defining an SPI message, the next member needs to be manipulated to confirm whether there is a next chained transmission. If not, it needs to be assigned to NULL. In the RT-Thread wiki, when using rt_spi_transfer_message to transmit two messages, the next of the second message is assigned to RT_NULL to indicate the end.
In the RT-Thread component, SPI-related operations also manipulate next and provide relevant comments for explanation.
3. Xianji BSP Adaptation
Some developers may ask, why do other BSP SPI drivers not have this issue? It can be seen in the RT-Thread mainline that most manufacturers (such as STM32) do not handle the next pointer in their SPI drivers, only supporting single message transmission, but chained transmission is prone to transmission exceptions due to unhandled next.
In contrast, the SPI driver of the Xianji BSP strictly implements the chained transmission logic according to RT-Thread specifications, enforcing validation of the next pointer. It supports both single and chained transmissions, compatible with complex scenarios.
4. Xianji BSP Support for DSPI and QSPI
Unlike other manufacturers’ BSPs, which separate SPI and QSPI into two driver files, Xianji integrates them into the SPI driver because the Xianji SPI itself is a peripheral that supports SPI, DSPI, and QSPI transmission modes.
To enable these three modes, you can enter the corresponding interface through menuconfig to select: single-line SPI, two-line DSPI, and four-line QSPI.
If you want to operate in RT-Thread Studio, you can do the following:
It should be noted that when using four-line QSPI, the corresponding pinmu.c SPI initialization needs to include the initialization of QSPI’s D2 and D3.
By using the list device command, you can see: SPI0 is single-line SPI, SPI1 is dual-line DSPI, and SPI2 is four-line QSPI.
5. Conclusion
The chained transmission trap: uninitialized next pointer is a common cause of exceptions in the SPI driver, and developers must strictly follow RT-Thread specifications.Xianji BSP advantages:1. Strictly adapts to RT-Thread chained transmission logic, avoiding illegal access.2. Integrates SPI/DSPI/QSPI drivers, simplifying the development process.