This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

The slow SPI transfer and interrupt issue

Hello tech support!

I am using the built-in SPI to transfer the data. Also, I adopted the "timer" example in the SDK for handling the SPI transfer. 

However, it seems that the SPI may be too slow and too much time is spent in the interrupt. When the timer interval is set as 10ms, the SPI transfer can run normally for 10-20mins then the transmitting string would be destroyed and fragmented. 

I have tried two method for SPI transfer. First one is the example SPI code given in the SDK, and second one is the SPI_master_fast method which is given in one of the post. 

However, it seems both of them fails. 

May I ask if there is anyway to speed up the SPI transfer?

Moreover, I am also wondering if there is any other interrupt which can slow down the SPI transfer which might be in the SoftDevice or any built-in application?

Many thanks!

Parents
  • Hi,

    Please provide more details on the issue.

    • How do you configure SPI? How/what are you transferring?
    • What are you doing in the interrupts? Is the issue with long handling of interrupt with timer or SPI?
    • What do you mean when you say the "string would be destroyed and fragmented"? Can you provide logic trace showing this behavior?
    • Which SDK version are you using?

    Softdevice will always have highest priority for handling timing-critical events. If you have a lot of BLE activity, this could cause delayed handling of SPI events.

    Best regards,
    Jørgen

Reply
  • Hi,

    Please provide more details on the issue.

    • How do you configure SPI? How/what are you transferring?
    • What are you doing in the interrupts? Is the issue with long handling of interrupt with timer or SPI?
    • What do you mean when you say the "string would be destroyed and fragmented"? Can you provide logic trace showing this behavior?
    • Which SDK version are you using?

    Softdevice will always have highest priority for handling timing-critical events. If you have a lot of BLE activity, this could cause delayed handling of SPI events.

    Best regards,
    Jørgen

Children
No Data
Related