A method and device for maintaining SPI slave multi-channel CAN (FD) message buffering and event status based on a general microcontroller
Patent Information
- Application Number
- CN202611249751.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-08-18
- Publication Date
- 2026-10-09
AI Technical Summary
[0007]要解决的技术问题：本发明要解决多路CAN(FD)异步报文与SPI主机访问之间的数据和事件状态一致性问题，尤其是接收缓冲区仍存在未读报文时接收可读事件被提前清除、多个通道事件共用一个INT引脚时通知状态与事件状态不一致、接收完整帧写入失败与正常接收事件混淆，以及主机读取后未读帧计数与事件状态不同步的问题
[0016]（2）仅在完整帧成功写入或完整取出后更新帧计数，避免半帧、失败操作和帧计数不一致。
Smart Images
Figure CN122891393A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of embedded communication data management technology, and specifically to a method, apparatus and system for associating and maintaining the complete message buffer, unread or pending frame count, event status and INT event notification conditions of each channel in an SPI slave multi-channel CAN(FD) communication device based on a general-purpose microcontroller.
[0002] The CAN(FD) channel referred to in this article is a CAN bus communication channel that can operate in classic CAN mode or CAN FD mode according to the channel configuration. Background Technology
[0003] In multi-channel CAN(FD) interface expansion devices, the arrival of CAN(FD) messages, controller state changes, and SPI master access are asynchronous. External hosts typically cannot continuously poll each CAN(FD) channel; they need to obtain information about pending data or abnormal states through event status and the INT pin.
[0004] If the receive readable event is treated as a regular flag, host clearing events, message arrival continuation, and host message reading may occur interchangeably. For example, if there are still unread messages in the receive buffer, and the host clears the receive readable event, the INT notification may be prematurely canceled, resulting in unread messages remaining in the buffer but the host no longer receiving notifications. Conversely, if all messages have been retrieved but the event has not been cleared, duplicate notifications will occur.
[0005] When multiple CAN (FD) channels and different types of events share a single INT event output, corresponding event flags need to be set separately in a unified event state. If there is no unified update rule for the event flags and the INT output state, the event state may change but the INT state may not change synchronously.
[0006] Therefore, it is necessary to establish a definite relationship between the total number of frame buffers, event states, and INT notification conditions, and to clearly define the state transition rules when the host reads packets, clears events, and handles exceptions. CS and BUSY can be used to define the boundaries of SPI transactions and command processing to ensure the complete execution of buffer, event state, and return data update processes. Summary of the Invention
[0007] The technical problem to be solved: This invention aims to solve the problem of data and event status consistency between multi-channel CAN(FD) asynchronous messages and SPI master access, especially the problem of receiving readable events being prematurely cleared when there are still unread messages in the receive buffer, the inconsistency between notification status and event status when multiple channel events share a single INT pin, the confusion between failure to write a complete frame and normal reception events, and the asynchrony between the unread frame count and event status after the master reads the data.
[0008] Technical Solution: This invention is applied to a general-purpose microcontroller that integrates one SPI slave peripheral, one INT event output terminal, and N CAN(FD) controllers on-chip. N is an integer greater than or equal to 2. The functional firmware establishes a receive buffer, a transmit buffer, a count of unread received frames, and a count of transmittable message frames for each CAN(FD) channel, and maintains the event status for representing preset events of each CAN(FD) channel and SPI interface.
[0009] The capacity of the receive buffer and transmit buffer for each CAN(FD) channel is pre-configured based on the on-chip memory capacity of the general-purpose microcontroller and determined during firmware compilation or initialization; the buffer is not dynamically allocated or its capacity is not adjusted during operation.
[0010] After a complete received message is successfully written to the corresponding CANn receive buffer, the unread frame count is incremented and the receive readable event flag is set. The unread frame count is decremented only after the complete message is retrieved from the receive buffer and loaded into the SPI transmit buffer. The receive readable event flag is maintained when the count after decrementing is greater than zero, and automatically cleared when the count after decrementing is zero. The receive readable event flag does not support clearing commands from external hosts; it is automatically set, maintained, or cleared along with the receive unread frame count of the corresponding channel.
[0011] The event status consists of multiple event flags, each indicating whether a preset event for the corresponding CAN(FD) channel or SPI interface has occurred. These flags include event flags for receive readability, receive frame loss, bus shutdown, and wake-up. When at least one event flag is valid, the unique INT event output is enabled to notify the external host; when all event flags are invalid, the INT event output is disabled. The INT output only indicates the existence of an event to be processed; the external host determines the specific channel and event type through the SPI event status read command.
[0012] When the CANn receive buffer is insufficient or a complete frame write fails, the count of unread frames remains unchanged, and the corresponding receive frame loss event flag is set. The receive readable event flag and the receive frame loss event flag indicate the presence of a readable message and the occurrence of received message loss, respectively, facilitating differentiation and processing by the external host.
[0013] After a message to be sent is successfully and completely written into the target channel's transmit buffer, the message frame count is incremented by one. The CAN transmit loop task retrieves a complete message frame and decrements the transmit frame count by one when the target CAN(FD) controller has the necessary loading conditions. If the transmit buffer is insufficient or a complete frame write fails, the count does not increase, and a corresponding write failure status is returned to the external host. This write failure status does not change the event status or the INT output status.
[0014] SPI access can employ an adjacent transaction return mechanism defined by the chip select signal and the BUSY busy status signal. The chip select signal determines the current transaction boundary, while BUSY covers command reception, command parsing, buffer access, frame counting and event status processing as needed based on the current command or event, return data loading, and SPI buffer reloading. The external host reads the current command result in subsequent SPI transactions after BUSY is released and can send the next command as needed in those subsequent SPI transactions. This interlocking mechanism ensures the complete completion of a state transition without altering the core technical solution that links buffer size and event status maintenance. Beneficial effects
[0015] (1) Bind the received readable event to the received unread frame count to avoid the INT notification being prematurely canceled when there are still unread messages in the buffer.
[0016] (2) Update the frame count only after a complete frame is successfully written or retrieved to avoid inconsistencies between half-frames, failed operations and frame counts.
[0017] (3) Use multiple event flag bits in the unified event state to represent the corresponding channel and event type, and control an INT event output terminal accordingly to ensure the consistency of the state when multiple channels and multiple events share a notification pin.
[0018] (4) The receive readable event flag does not respond to the clear event command. It is only automatically set, maintained or cleared as the number of unread frames received increases, to avoid missing notifications when the host clear event and new messages arrive.
[0019] (5) Events such as frame loss, bus shutdown and wake-up are separated from normal readable events, which facilitates external host diagnosis; CS and BUSY can further limit the host access order to ensure that the returned data, frame count, event status and INT notification conditions are synchronized and updated before the host accesses them.
[0020] This invention enables a general-purpose microcontroller to reliably notify preset events of multiple CAN(FD) channels and SPI interfaces via an INT event output, while maintaining consistency in the number of complete frames in the buffer, event status, and host notification conditions. Attached Figure Description
[0021] Figure 1 This is a schematic diagram of the overall structure of SPI command processing, message counting, and INT event processing according to an embodiment of the present invention.
[0022] Figure 2 This is a schematic diagram illustrating the linkage maintenance process of receiving unread frame count, receiving readable events, and INT notification conditions according to an embodiment of the present invention.
[0023] Figure 3 This is a schematic diagram of the SPI adjacent transaction return and BUSY interlocking process according to an embodiment of the present invention. Detailed Implementation
[0024] like Figure 1 As shown, the external host sends commands to the slave device via SPI and obtains the status of the INT and BUSY signals; the slave device receives and parses the SPI commands, identifies the operation type and target CAN (FD) channel, performs message processing, frame counting and event status maintenance for the corresponding channel, and controls the INT event output terminal according to the current event status.
[0025] In this embodiment, the slave device is implemented by a general-purpose microcontroller that integrates one SPI slave peripheral, one INT event output, one BUSY busy status output, and N CAN(FD) controllers. The functional firmware establishes receive buffers, transmit buffers, unread frame counts, and transmit message frame counts for CAN0 to CAN(N-1), respectively. The capacity of each buffer is determined during firmware compilation or initialization and is not dynamically allocated or adjusted during operation.
[0026] The functional firmware also maintains event states that can distinguish between channels and event types. These event states consist of multiple event flags, including flags for each CAN (FD) channel's receive readable, receive frame lost, bus off, and wake-up events, as well as an SPI wake-up event flag. In this embodiment, event states are expressed as event state words, and the external host reads the event states once using a preset event state read command. When any event flag is valid, the INT output control module makes the unique INT event output terminal valid; when all event flags are invalid, the INT event output terminal is invalidated. The valid level or valid edge of INT can be determined according to the hardware interface configuration.
[0027] After CANn receives the callback and reads the hardware message, it can enter... Figure 2 Channel filtering is performed before the process shown. Packets that fail filtering are not written to the receive buffer; complete packets that pass filtering enter the receive buffer. Figure 2The diagram illustrates the linked maintenance process for buffer writing, unread frame counting, and event status. When the receive buffer has sufficient space to hold the complete message and the write operation is successful, the CANn unread frame count is incremented and the corresponding receive readable event flag in the event status is set. When the receive buffer is insufficient or the complete frame write operation fails, no half-frame is written, the CANn unread frame count remains unchanged, and the corresponding receive lost frame event flag is set. The INT event output remains valid as long as a valid event flag exists in the event status.
[0028] After the external host reads the event status, it determines the channel and event type based on the valid event flags and sends a command to read the CANn message. The functional firmware retrieves a complete frame from the CANn receive buffer and loads it into the SPI transmit buffer, then decrements the CANn unread frame count by one. If the count after decrementing is greater than zero, the corresponding receive readable event flag is maintained; if the count after decrementing is zero, the event flag is automatically cleared. Subsequently, the INT event output is controlled based on the current event status, rather than directly decrementing the INT based on this message read operation.
[0029] Upon receiving a host-clear event command, the functional firmware clears event flags that can be cleared by the external host, such as those for received frame drops, bus shutdown, or wake-up, according to the event mask, while maintaining the receive readable event flags for each channel unchanged. The receive readable event flag is not among the event flags that can be cleared by the clear event command; it is only automatically cleared when the count of unread received frames for the corresponding channel reaches zero. After the clear event operation is completed, the current event status is summarized, and the INT event output is invalidated only when all event flags are invalid. Therefore, although different channels and different events share a single INT event output, clearing one event will not cause other still existing events to be missed.
[0030] like Figure 3 As shown, the external host first confirms that BUSY is in the released state, then pulls CS low and sends the current command k. The slave device detects the falling edge of CS and sets BUSY to the next bit, then starts SPI data transmission and reception; after the host pulls CS high to end transaction k, the slave device parses the command code and corresponding command data received in this SPI transaction.
[0031] The slave device parses the command code and corresponding command data according to a preset command list. For commands involving a specified CAN (FD) channel, the target CAN (FD) channel is determined by the command code itself or the channel selection information in the command data, and the corresponding operation is executed according to the parsing result.
[0032] After command parsing is complete, the slave device performs the corresponding buffer access and state transition. For commands or events that cause changes in frame count or event state, the event flag is set, maintained, or cleared according to the corresponding event type and frame count, and the INT event output is controlled according to the current event state. Subsequently, the slave device loads the return data of command k into the SPI transmit buffer, and releases BUSY after completing the loading of the SPI transmit and receive buffers. The external host reads the return data of command k in subsequent transaction k+1 and can send subsequent commands as needed according to the preset command format.
[0033] In this embodiment, the external host accesses the slave device via the SPI signal lines consisting of SCK, MOSI, MISO, and CS, as well as the INT and BUSY signal lines. INT is used to notify the external host that a valid event exists in the event status, and BUSY is used to indicate that the slave device is executing SPI command processing and preparing to return data. Each CAN (FD) channel and different event types share a single INT event output terminal.
[0034] The external host sends a write CAN(FD) message command and determines the target CAN(FD) channel based on the command code itself or the channel selection information in the command data. After the message data passes the check and the complete message is successfully written to the target channel's transmit buffer, the transmit frame count is incremented and a success return data is generated; if the transmit buffer space is insufficient or the complete frame writing fails, the transmit frame count remains unchanged and a failure return data is generated.
[0035] The CAN transmit cycle task checks whether the CANn controller has the loading conditions. If the conditions are met and the count of messages to be transmitted is greater than zero, a complete frame is retrieved from the CANn transmit buffer and loaded into the controller, and then the count of messages to be transmitted is decremented by one. When a preset event such as bus shutdown occurs in the CANn controller, the corresponding event flag bit in the event status is set, and it is not confused with the count of messages to be transmitted.
[0036] When any CAN(FD) channel receives a complete message, but the corresponding receive buffer has insufficient remaining space or the complete message writing fails, an incomplete message is not written to the receive buffer. The unread frame count for that channel remains unchanged, and the corresponding receive frame loss event flag is set. If the receive frame loss event flag is present in the event status, the INT event output is made valid to notify the external host to read the event status and perform corresponding processing.
[0037] When any CAN(FD) controller detects a bus shutdown, wake-up, or other preset bus status event, it sets the event flag for the corresponding channel and event type in the event status and controls the INT event output terminal according to the updated event status. After receiving the INT event notification, the external host reads the event status via SPI to determine the CAN(FD) channel and event type where the event occurred, and sends status read, restore, or reinitialize commands as needed.
[0038] When an external host sends a write CAN(FD) message command, but the target channel's transmit buffer space is insufficient or the complete message write fails, the transmit queue frame count remains unchanged, and a write failure status is returned to the external host via SPI. The write failure in the transmit buffer does not set the event flag, nor does it change the INT event output status.
[0039] For the receive readable event flag, it is only set, held, or automatically cleared according to the count of unread frames received for the corresponding channel, and does not respond to the clear event command sent by the external host; for event flags that can be cleared by the external host, such as received frame loss, bus shutdown, or wake-up, they are cleared according to the event mask in the clear event command.
Claims
1. A method for buffering and maintaining the event status of SPI slave multi-channel CAN(FD) messages based on a general-purpose microcontroller, characterized in that, This method is applied to a general-purpose microcontroller that integrates one SPI slave peripheral, one INT event output, and N CAN (FD) controllers on-chip, where N is an integer greater than or equal to 2. The method includes: establishing a receive buffer and a receive unread frame count for each CAN (FD) channel, and maintaining an event state consisting of multiple event flags; when a complete message received by any CAN (FD) channel is successfully written to the corresponding receive buffer, incrementing the receive unread frame count of that channel and setting the corresponding receive readable event flag; when a complete message is read from the receive buffer according to a read command from an external host... When a frame is extracted and loaded into the SPI transmit buffer, the unread frame count of the channel is decremented by one. If the unread frame count after decrementing is greater than zero, the corresponding readable event flag is maintained. If the unread frame count after decrementing is zero, the corresponding readable event flag is cleared. The readable event flag does not respond to the clear event command from the external host; it is automatically set, maintained, or cleared according to the unread frame count of the corresponding channel. When at least one event flag is valid in the event state, the INT event output is valid; when all event flags are invalid, the INT event output is invalid.
2. The method according to claim 1, characterized in that, In the CAN(FD) receive callback, the validity of the message identifier is determined according to the filtering configuration of the target channel. If the message identifier is valid and the receive buffer can hold the complete message, it is written to the receive buffer as a complete frame. If the message identifier is invalid, it is not written to the receive buffer. If the receive buffer space is insufficient or the complete frame writing fails, the unread frame count is kept unchanged and the corresponding received frame loss event flag is set.
3. The method according to claim 1, characterized in that, In addition to the receive readable event flag, the multiple event flags also include at least one of the receive frame loss, bus shutdown, or wake-up event flags; different CAN (FD) channels and different event types share the INT event output terminal, and the external host reads the event status through SPI to determine the corresponding channel and event type.
4. The method according to claim 3, characterized in that, The external host clears at least one of the event flags for frame loss, bus shutdown, or wake-up by using a clear event command with an event mask. After executing the clear event command, the INT event output remains valid if there are still valid event flags in the event state, and invalidates the INT event output if all event flags are invalid.
5. The method according to claim 1, characterized in that, The general-purpose microcontroller also includes a BUSY state output terminal; when the SPI chip select signal is valid, the BUSY state signal is set and the current command is received; when the SPI chip select signal is invalid, command parsing, buffer access, and frame counting and event status processing are performed according to the current command or event. After the return data is loaded, the BUSY state signal is released so that the external host can read the return data of the current command in subsequent SPI transactions and send subsequent commands as needed in the subsequent SPI transactions.
6. The method according to claim 1, characterized in that, Each CAN(FD) channel is also configured with a transmit buffer and a transmit frame count. When a complete message is successfully written to the transmit buffer of the target channel, the transmit frame count is incremented by one. If the write fails, the transmit frame count remains unchanged, and a write failure status is returned to the external host via SPI. When the target CAN(FD) controller has the loading conditions and the transmit frame count is greater than zero, a complete message frame is retrieved from the transmit buffer and loaded into the target CAN(FD) controller, while the transmit frame count is decremented by one.
7. A device for buffering and maintaining the event status of SPI slave multiplexed CAN(FD) messages based on a general-purpose microcontroller, characterized in that, The system includes a general-purpose microcontroller and functional firmware stored in the on-chip non-volatile memory of the general-purpose microcontroller. The general-purpose microcontroller integrates one SPI slave peripheral, one INT event output terminal, and N CAN (FD) controllers, where N is an integer greater than or equal to 2. The functional firmware is used to maintain a receive buffer, a receive unread frame count, and a corresponding event flag for each CAN (FD) channel. When a complete message is successfully written, the receive unread frame count is incremented and the receive readable event flag is set. When a complete message is read by the host, the receive unread frame count is decremented and the receive readable event flag is maintained or cleared based on the decremented count. The system also controls the INT event output terminal based on whether a valid event flag exists in the event status.
8. The apparatus according to claim 7, characterized in that, The functional firmware includes a buffer management module, a frame count maintenance module, an event status maintenance module, an INT output control module, and an SPI command processing module configured by channel. When a preset event occurs or a complete message is read, the event status maintenance module sets, maintains, or clears the corresponding event flag according to the corresponding event type and the number of unread frames received. When the event clear command is executed, it only clears other event flags that can be cleared by the external host according to the event mask, and does not clear the received readable event flag. The INT output control module controls the INT event output terminal according to the current event status.
9. The apparatus according to claim 7 or 8, characterized in that, The functional firmware is also used to set a transmit buffer and a transmit frame count for each CAN(FD) channel; when a complete message is successfully written to the transmit buffer of the target CAN(FD) channel, the corresponding transmit frame count is incremented by one; when the target CAN(FD) controller has the message loading conditions and the corresponding transmit frame count is greater than zero, a complete message frame is retrieved from the transmit buffer and loaded into the target CAN(FD) controller, while the transmit frame count is decremented by one; when writing a complete message to the transmit buffer fails, the transmit frame count remains unchanged, and a write failure status is returned to the external host via SPI.
10. A communication control system, characterized in that, Includes an external host and the apparatus of claim 7 or 8; after receiving an INT event notification, the external host reads the event status via SPI, determines the corresponding channel and event type based on the valid event flag, and sends a read message command or exception handling command corresponding to the determined channel; After the device completely retrieves the message, updates the unread frame count and the corresponding event flag, it controls the INT event output terminal according to the updated event status.