SAM4S microcontroller not detecting pin change interrupt

[calvingloster]

Hi All

I have setup a SAM4SD32C microcontroller in SPI SLAVE mode to read a SPI bus from a Tango 2 drone transmitter remote. My intension is to sniff the GPS co-ordinates from the SPI data stream and process it for my ground station. I've connected it to a logic analyzer and successfully found which packet contains the GPS co-ords. The problem is there is a lot of packets sent really quickly after each other and the CSS pin of the slave asserts so fast(300ns) it does not get detected by the SPI ISR. The microcontroller clock is running at 120MHz.

Below is the ISR just for test purposes . I am simply trying to verify that the pin change interrupts on the CSS pin is working. What I find is that it only works when the pin state changes for about 800ns or so. Is this microcontroller simply too slow? the micro of the SPI master is running at 168 MHZ so not much faster.

Code: [Select]

void SPI_Handler() {

status = REG_SPI_SR;

// Handle received data
if (status & SPI_SR_RDRF) {
uint8_t dataDiscard = REG_SPI_RDR;
}

if (status & SPI_SR_NSSR) {

if (PIOA->PIO_PDSR & PIO_PA11)  // CSS pin is high
{
REG_PIOC_CODR = PIO_PER_P22;
}

else // NSS pin is low
{
REG_PIOC_SODR = PIO_PER_P22;
}

}

}


Below is a picture of the logic analyzer showing that the CSS change does not get picked up when CSS goes high for 296ns and then low again. The data sheet of the SAM4S says the CSS pin min setup and hold time is 3 to 4ns. Not sure if I'm reading this correctly?

[ataradov]

Setup and hold times have nothing to do with the change detection. Those values are only applicable to the shift register correctly sampling the bits.

By the time you get into the NSSR interrupt, reading the port is too late. SPI will detect the change, but by the time you are in the handler, it already would be back.

If NSSR flag is set, then SPI sees the transition, the handler code is just too slow to react.

[calvingloster]

Thanks for that it makes sense now. How would I get around this slow response for detecting the beggining and end of a packet frame? From you explaination if I understand correctly, the SPI peripheral will be getting the data in no problem but some packets contain 2 bytes, some contain 14, some 4 etc. My intension was to monitor how long each frame is by watching if CSS goes low (start of frame) or CSS goes high (end of frame) because I am interested in frames with 14 bytes only that contain th GPS co-ordinate. Is this approach flawed?

[ataradov]

You will be getting NSSR flag, which separates the packets. You don't need to look at the line state in the code.

In your ISR look at the NSSR first. If set, you know that the next byte will belong to the next packet and you can terminate the current one.

So, you collect the bytes until NSSR arrives. When it arrives, see hoe many bytes were received so far and discard the packet if it is not the right length.

[calvingloster]

You sir are smart man. Thanks