MCU: MK20DX256
Code warrior: 10.6
I am using processor expert to generate SPI driver for our project. The SPI driver is used to communicate with a flash chip. The chip select of the flash chip is pulled high(active low) when a transaction(all bytes are sent) with the flash is over. We are using the 'OnBlockSent' event by the PE generated code to disable the chip select pin. We have observed that the 'OnBlockSent' event is generated before all bytes are transmitted in the SPI line. We tried diving into the generated code to see if any thing is wrong, we observed that the 'OnBlockSent ' is immediately called after the last byte of the requested sent block is put to the H/W buffer. This means when the 'OnBlockSent' event is called there could be one byte in the SPI PISO to be transmitted and another pending byte in the hardware buffer(our hardware buffer size is 1). Below is the H/W buffer configuration:
Below is the ISR implementation where we observed the behavior:
PE_ISR(SM1_Interrupt)
{
/* {Default RTOS Adapter} ISR parameter is passed through the global variable */
SM1_TDeviceDataPtr DeviceDataPrv = INT_SPI1__DEFAULT_RTOS_ISRPARAM;
uint32_t StatReg = SPI_PDD_GetInterruptFlags(SPI1_BASE_PTR); /* Read status register */
uint16_t Data; /* Temporary variable for data */
if ((StatReg & SPI_PDD_RX_FIFO_OVERFLOW_INT) != 0U) { /* Is any error flag set? */
SPI_PDD_ClearInterruptFlags(SPI1_BASE_PTR,SPI_PDD_RX_FIFO_OVERFLOW_INT); /* Clear error flags */
}
if ((StatReg & SPI_PDD_RX_FIFO_DRAIN_INT_DMA) != 0U) { /* Is any char in HW buffer? */
Data = (uint16_t)SPI_PDD_ReadPopRxFIFOReg(SPI1_BASE_PTR); /* Read character from receiver */
SPI_PDD_ClearInterruptFlags(SPI1_BASE_PTR,SPI_PDD_RX_FIFO_DRAIN_INT_DMA); /* Clear Rx FIFO drain flags */
if (DeviceDataPrv->InpDataNumReq != 0x00U) { /* Is the receive block operation pending? */
*(DeviceDataPrv->InpDataPtr++) = (uint8_t)Data; /* Put a character to the receive buffer and increment pointer to receive buffer */
DeviceDataPrv->InpRecvDataNum++; /* Increment received char. counter */
if (DeviceDataPrv->InpRecvDataNum == DeviceDataPrv->InpDataNumReq) { /* Is the requested number of characters received? */
DeviceDataPrv->InpDataNumReq = 0x00U; /* If yes then clear number of requested characters to be received. */
SM1_OnBlockReceived(DeviceDataPrv->UserData);
}
}
}
if ((StatReg & SPI_PDD_TX_FIFO_FILL_INT_DMA) != 0U) { /* Is HW buffer empty? */
if (DeviceDataPrv->OutSentDataNum < DeviceDataPrv->OutDataNumReq) { /* Is number of sent characters less than the number of requested incoming characters? */
DeviceDataPrv->OutSentDataNum++; /* Increment the counter of sent characters. */
SPI_PDD_WriteMasterPushTxFIFOReg(SPI1_BASE_PTR, (uint32_t)(*((uint8_t *)DeviceDataPrv->OutDataPtr++) | DeviceDataPrv->TxCommand)); /* Put a character with command to the transmit register and increment pointer to the transmitt buffer */
if (DeviceDataPrv->OutSentDataNum == DeviceDataPrv->OutDataNumReq) {
DeviceDataPrv->OutDataNumReq = 0x00U; /* Clear the counter of characters to be send by SendBlock() */
SM1_OnBlockSent(DeviceDataPrv->UserData);
}
} else {
SPI_PDD_DisableDmasInterrupts(SPI1_BASE_PTR, SPI_PDD_TX_FIFO_FILL_INT_DMA); /* Disable TX interrupt */
}
SPI_PDD_ClearInterruptFlags(SPI1_BASE_PTR,SPI_PDD_TX_FIFO_FILL_INT_DMA); /* Clear Tx FIFO fill flags */
}
}
Question:
1. Isn't this implementation wrong, shouldn't 'OnBlockSent' be called after all bytes are put to the SPI line ?
2. What is the way we could figure out all SPI bytes are transmitted onto the SPI bus ?
Hello Alexis,
The FIFO Hardware buffer for Tx/ Rx and the Shift Register are different entities. I am attaching the users manual for your reference. The microcontroller has the following architecture:-
"SPI_PDD_WriteMasterPushTxFIFOReg" function is used to push a byte of data into the FIFO register upon the invocation of "Tx FIFO not Full Interrupt".
"if ((StatReg & SPI_PDD_TX_FIFO_FILL_INT_DMA) != 0U)" in the code is used to check if the Tx Buffer is not full. When the buffer is not full a byte of data is pushed by copying from a pointer to a bytearray in RAM to this Tx buffer using "SPI_PDD_WriteMasterPushTxFIFOReg".
You can verify this by looking into the macro definition of SPI_PDD_TX_FIFO_FILL_INT_DMA which is equal to 0x2000000 which masks the 25th bit in the status register. Please refer to the attached image on the left.
The data is then transferred from the Tx Buffer to the shift register from which the data is transmitted over the MOSI pin of the controller. When the shift register transfers the data, the TCF (Transmission complete Flag) is set and the TXNXTPTR gets updated which points to the next byte of data in FIFO Tx buffer that needs to be placed in shift register.
The processor Expert configures the interrupt only for TFFF flag and not for TCF flag, so the call back "SM1_OnBlockSent" event happens while there is still a residual data in Tx FIFO buffer. Please have a look into the send script implemented by processor Expert:-
So if we are transmitting 3 bytes of data, the Tx FIFO not full interrupt is configured so in the first interrupt we push 1 byte of data to Tx FIFO buffer and we increment number of bytes sent by 1, Tx FIFO buffer internally puts this 1 byte of data to the Shift register and the Tx FIFO not full interrupt is triggered again, now a second byte of data is placed into the Tx FIFO buffer and the number of bytes sent is now 2. After the shift register transmits the 1st byte, Tx FIFO puts second byte of data into the Shift register and Tx FIFO causes another interrupt upon which 3rd byte of data is pushed into Tx FIFO buffer and the number of bytes sent is incremented to 3. At this stage Number of bytes sent is equal to the number of bytes requested to be sent so the PE_ISR function calls back the SM1_OnBlockSent function in events.c. But this is not expected because there is a byte of data in the Tx FIFO buffer and another byte of data which is in transmission state in the shift register.
The major problem arises because the event SM1_OnBlockSent is used for (de)asserting CS pin to mark the end of transmission. The calling of SM1_OnBlockSent is based upon counting number of bytes put into the Tx FIFO buffer so (de)asserting CS pin would cause unexpected communication errors.
Cheers,
Prajwal B V
Hi Alexis,
The claim you made is as following:-
When the first time interruption is called, one byte is already sent.
It is incorrect because we have verified it while debugging by putting a breakpoint inside the interrupt, we found that when the first interrupt happens the following command is used to push 1st byte of data into FIFO buffer, not the second byte as per the claim.
SPI_PDD_WriteMasterPushTxFIFOReg(SPI1_BASE_PTR, (uint32_t) ( * ( (uint8_t *) DeviceDataPrv->OutDataPtr++) | DeviceDataPrv->TxCommand) );But let us try to assume the claim is true and logically try to verify w.r.t to the configuration and the actual code generated by processor expert:-
I think you haven't understood my previous reply about the interrupt. So I explaining it again here, the interrupt that is configured by processor expert is not the transmission complete interrupt but it is the buffer not full interrupt. This can be verified from the Flag mask that is used to configure and check the interrupt status in the code:-
The value of SPI_PDD_TX_FIFO_FILL_INT_DMA is 0x02000000 which is equal to 0b00000010000000000000000000000000 in binary, so it is used to mask the 25th bit
| 32 | 31 | 30 | 29 | 28 | 27 | 26 | 25 | 24 | 23 | 22 | 21 | 20 | 19 | 18 | 17 | 16 | 15 | 14 | 13 | 12 | 11 | 10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
Now consider the Interrupt Status Register, the 25th bit is mapped to TFFF Flag which is raised once the FIFO buffer is empty.
We can also see why the claim is false by logically verifying the code:-
Lets assume that the claim is true, so when the first time the interruption is called for transmitting data, the execution happens in the marked code snippet shown below.
Lets say we have 2 bytes of data to be transmitted using SPI which is {0x01, 0x02} for analysys:-
Step 1:- The code executes only if this line is true, since the assumption is that the first byte was transmitted, the buffer is not full and the if condition is true
if (StatReg & SPI_PDD_TX_FIFO_FILL_INT_DMA) ! = 0U) Step 2:- The next condition is also true since only 1 byte is transmitted, i.e the byte transmitted is lesser than bytes requested to transmit.
if (DeviceDataPrv->OutSentDataNum < DeviceDataPrv->OutDataNumReq)Step 3:- In this line the variable that keeps track of the number of bytes that is sent gets incremented, so now:-
DeviceDataPrv->OutSentDataNum++- since the claim was 1 byte was already sent (which is 0x01), this gets incremented to value 2 which is wrong because it should have incremented after the transmission according to the claim.
DeviceDataPrv->OutSentDataNum++Step4:- The command is supposed to push a byte of data from the array pointer to the FIFO Register.
SPI_PDD_WriteMasterPushTxFIFOReg(SPI1_BASE_PTR, (uint32_t) ( * ( (uint8_t *) DeviceDataPrv->OutDataPtr++) | DeviceDataPrv->TxCommand) );- So if the claim is 1 byte of data is already transmitted in first interrupt, then how did the pointer got incremented to point to the second byte? So again there is a problem. Lets say it somehow got incremented to point to second data, now when it is incremented again, it will be pointing to the 3rd byte.
- Previously in Step 3 we assumed that OutSentDataNum it is incremented to 1 from 0 and because of this in the next interrupt Step 1 is true, Step 2 is also true, Step 3 OutSentDataNum is incremented to 2 and in Step 4 we are trying to access the 3rd byte and so the system will throw Bus Fault.
What is the explanation for the issues that I have mentioned in Red with that claim.
Regards,
Prajwal B V
