In my application, I have two TC367 controllers on the same PCB (ECU) and QSPI0 from Controller1 is connected to QSPI0 of Controller2. QSPI0 on controller1 shall be configured as MASTER and QSPI0 on controller2 as SLAVE. And I need to establish the communication between two controller via QSPI/DMA.
My requirement is to have around 20~30bytes periodic communication @ 5Mhz baud-rate.
Using QSPI Long Mode and DMA, by enabling QSPI Tx and Rx interrupts to DMA Channels 8, 9. I am triggering Tx in a 1ms periodic runnable by updating the BACON configuration register.
I have a total of 6 x 32-bit buffers as I want to transmit 24bytes as one frame. Master side Tx/Rx seems to be working fine, but the data from Slave has some problem. Among the 6x32-bit buffers, MASTER is receiving correct value for only 1st buffer as shown in the below picture.
It seems DATAENTRY register on SLAVE controller is not getting updated properly via DMA... So, slave is sending all "1". I tried few methods like to update BACONETRY on slave controller within the DMA Transaction complete ISR routine, but nothing seems to be working.. After comparing DMA registers between Controller1 (MASTER) and Controller2(SLAVE), I noticed HTRE bit is flickering between Enabled/Disabled, which doesn't happen on Controller1.
I am attaching my code here. Would someone please provide any suggestions to resolve this issue?
** Please note that I have same software (hex file) running on both controllers. But I differentiate the code in the software for both controllers based on a particular GPIO pins status. If these GPIO pins set to high, it means that is controller #2. When I power-up the ECU, both controllers will startup approximately the same time.
Can anyone please suggest your opinion? When I looked at the QSIP status register, ERRORFLAG is set, which is TXFIFO underflow error in slave mode. So, I tried by updating the DATAENTRY registers during the Controller's initialization sequence on SLAVE MCU, so its TXFIFIO will be filled with data before the 1st Rx message is received. But, it still doesn't change the behavior.
There is the following description in the User Manual.
I hope this will help.
//37.3.3 Slave Mode
In case of slave transmit, the user software must write data to the TXFIFO before the first SCLKI edge of a frame arrives. If the TXFIFO is empty at this point of time, an underflow occurs, all “1” data is delivered, and underflow error interrupt is triggered if enabled. If the TXFIFO is written at the same time when the first SCLKI edge starts the shifting, the underflow occurs, interrupt will be triggered and data from the TXFIFO will be transmitted possibly corrupted - the first bit will be “1”.
In case of TXFIFO / RXFIFO underflow the fifos deliver all “1” data.
This document (Infineon-AURIX_TC3xx_Part2-UserManual-v01_00-EN.pdf) is obtained from:
If you have access to MyICP, please refer to the latest documentation.
To me it seems like chip select issue. i will suggest you to connect an osci and proof the signals. it will help you to identify the problem.
Thank you both for the feedback. I actually updated my logic in both MASTER and SLAVE controller to use "Short_Continuous" mode (with reference to the example bare metal code provided in the link below) instead of "Long Mode" and the communication is working fine.
However, I am facing a new issue. I am periodically re-enabling the DMA in both Master and Slave controllers. The Communication seems to be working fine without any errors when this period is more than 20ms.. But, as soon as I increase the periodicity to say 10ms.. (i.e. every10ms, both controllers enable their DMAs to trigger Tx), SLAVE side Rx doesnt work properly.. Slave controller keep setting QSPI error flags 4 (Tx FIFO underflow) and 5 (RXFIFO overflow).
I tried some combinations like checking SLAVE QSPI TXFIFO LEVEL before enabling SLAVE controllers RX DMA transfer to make sure SLAVE TXFIFO level is full. But, it doesn't work. It seems I am missing some hand-shaking logic on Slave.. so we make sure SLAVE TX FIFO is full and ready before it can receive data from MASTER?
Any thoughts or suggestions?
It seems like I finally got it working.
<< My use case/requirements >>
- Need 6 words of data exchange between Master and Slave controller in Long Mode (32-bit exchange) using DMA
<< Implementation details>>
- Configure QSPI as Long Mode (BACON.BYTE = 1, BACON.LAST = 1, BACON.DL = 23) in Master MCU
- Master MCU triggers QSPI frame in a periodic function (1ms) by starting Master_DMA_Tx transaction for 6 words (6x32-bit = 24bytes). This DMA transaction copies 6 words of Master_txRAMBuffer --> DATAENTRY0 ~ DATAENTRY5.
- Using QSPI Rx Interrupt as DMA, Slave MCU reads the data from RXEXIT for 6 words (RXEXIT --> Slave_rxRAMBuffer)
- After completing Slave_DMA_RX transaction, DMA complete CPU ISR is triggered on Slave
- Inside this ISR, I trigger Slave_DMA_Tx to transfer 6 words from Slave_txRAMBuffer --> DATAENTRY0 ~ DATAENTRY5
After implementing above logic and Powerup both controller at the same time. For the first few cycles, I see QSPI on Slave MCU setting TXFIFO Underflow (SlaveMode) error as Slave will not have any data in its TXFIFO when the very first frame is received. From next (2nd) frame, since Slave updates DATAENTRY registers (0~5), Slave FIFO will have its data ready and doesn't set TXFIFO underflow error any more. In my use case it is okay if there are TXFIFO underflow errors for 1st few frames.
- Can someone suggest if there is any errors in the above concept?
- The main thing I am little concerned or not completely confident is updating DATAENTRY registers 0 ~ 5 on the Slave MCU. As we know that FIFO size is limited to 4 words, but in my use case I need 6 words.. So, using QSPI long mode, I am updating 6 DATAENTRY (0~5) registers via DMA on SLAVE MCU after completing the reception of the frame. By doing this, from 2nd Frame, as the Slave MCU receives data, TXFIFO gets updated with data from DATAENTRY registers 0 ~ 6. Is my assumption correct? Can you please let me know if there is any concerns related this concept?
Really appreciate your guidance.