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

nrf51822 corrupt data by SoftDevice interrupt

Dear Nordic.

I read specific data using GPIO(timer sampling), BUT, occasionally, the data is broken because of Softdevice interrupt. So I want to guarantee it while reading a data.

please tell me to solve a issue, if you have a solution.

Thanks

Parents
  • There must be at least one post a week where someone is trying to do high-precision timing operations using interrupts with the softdevice running. You can't do it. All the timings and all the interrupt priorities are spelled out in the documentation, the softdevice has the highest interrupt priority and it needs it in order to keep the connection alive, bluetooth has very specific timing requirements. You are going to be interrupted, the softdevice is going to take a certain amount of time to do its work (again all in the manual) and your interrupts will be delayed when this happens.

    The only options you have are

    1. Use the hardware features of the chip. Use GPIOTE events and PPI channels to trigger captures and then read the captured data when your interrupt handler does run.
    2. Use a second chip dedicated to reading the data and buffering it and read off of that
    3. If the data looks like a standard data stream the nRF51 chip has hardware to read, use that hardware.
Reply
  • There must be at least one post a week where someone is trying to do high-precision timing operations using interrupts with the softdevice running. You can't do it. All the timings and all the interrupt priorities are spelled out in the documentation, the softdevice has the highest interrupt priority and it needs it in order to keep the connection alive, bluetooth has very specific timing requirements. You are going to be interrupted, the softdevice is going to take a certain amount of time to do its work (again all in the manual) and your interrupts will be delayed when this happens.

    The only options you have are

    1. Use the hardware features of the chip. Use GPIOTE events and PPI channels to trigger captures and then read the captured data when your interrupt handler does run.
    2. Use a second chip dedicated to reading the data and buffering it and read off of that
    3. If the data looks like a standard data stream the nRF51 chip has hardware to read, use that hardware.
Children
No Data
Related