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

nRF52840 SPI init hangs after event loop starts

Hi,

My project uses nRF52840 with SD 140, SDK 17.0.2 and SES.  My hardware has SD Card SPI and LCD SPI sharing bus pins, using CS pins to switch devices.  Because of this each device needs to be uninitialized before starting comms with the other.  Essentially my code flow goes:

Initialize SD card -> Read bmp file from SD -> Uninitialize SD -> Initialize LCD -> Display bmp on screen -> Uninitialize LCD

This all works fine when called from my main() function.  I can display as many bmp images in a row as I desire.  The problem occurs once the event loop has started.   Both the SD card and LCD will not initialize from an event handler function.  The SD card hangs at m_drives[drv].config.wait_func(); in diskio_blkdev.c or the LCD hangs at while(!m_spi_xfer_done)  after calling nrfx_spim_xfer();.  I have tried using a bsp event (pressing board button) and also a ble write event (writing to custom characteristic).  I have tried using SPI Instances 0, 1, and 2 with same results.

I don't understand how it can initialize and unitialize 10 times in a row with no issues before any event handlers run but it seems deadlocked afterwards?  It seems to me there could be an issue with the soft device causing interference with the spi bus?

EDIT: It appears I might have an interrupt issue?  But if I set NRFX_SPIM and SPI_ENABLED irq priority to 3 or 5 I get hard fault when event handler routine is called

Parents
  • Hello poolshark021,

    EDIT: It appears I might have an interrupt issue?  But if I set NRFX_SPIM and SPI_ENABLED irq priority to 3 or 5 I get hard fault when event handler routine is called

    Could you elaborate what you mean when you say hard fault?
    Is the device resetting of itself, or is anything written to the log?
    Please ensure that you have DEBUG defined in your preprocessor defines like shown in the included image, to make sure a debug output is printed when an error occurs.

    This all works fine when called from my main() function.  I can display as many bmp images in a row as I desire.  The problem occurs once the event loop has started.   Both the SD card and LCD will not initialize from an event handler function.  The SD card hangs at m_drives[drv].config.wait_func(); in diskio_blkdev.c or the LCD hangs at while(!m_spi_xfer_done)  after calling nrfx_spim_xfer();

    Yes, this definitely sounds like a interrupt priority issue.
    What is the priority you are using for the interrupt handler which you would like to initialize the SPI instances from, and what is the priority of the SPI instances?
    The best illustration of this issue is how the LCD hangs on !m_spi_xfer_done - this is a flag which should be set as part of the SPI event handler ( on a TX / RX complete event ), but if the waiting occurs in an interrupt with a equal or higher priority than the SPI interrupt, the SPI interrupt will never get to process - because it is waiting for the interrupt that contains the SPI init to finish - and that interrupt will never finish, because it is waiting for the SPI event handler to toggle the flag.
    This is likely the cause of the deadlock you are seeing - its quite a common issue when working with different priority interrupts that depend on each other.

    The reason why everything works in you main context is because it has the lower priority, which means it will be interrupted by any interrupt regardless of priority level. Thus, whenever a interrupt (such as the SPI RX / TX complete event ) occurs, it is immediately processed. You can read more about the different interrupt priorities here.

    I think we will be able to resolve this issue as soon as we know what priority the different interrupts have in your application.

    Looking forward to resolving this issue together!

    Best regards,
    Karl

Reply
  • Hello poolshark021,

    EDIT: It appears I might have an interrupt issue?  But if I set NRFX_SPIM and SPI_ENABLED irq priority to 3 or 5 I get hard fault when event handler routine is called

    Could you elaborate what you mean when you say hard fault?
    Is the device resetting of itself, or is anything written to the log?
    Please ensure that you have DEBUG defined in your preprocessor defines like shown in the included image, to make sure a debug output is printed when an error occurs.

    This all works fine when called from my main() function.  I can display as many bmp images in a row as I desire.  The problem occurs once the event loop has started.   Both the SD card and LCD will not initialize from an event handler function.  The SD card hangs at m_drives[drv].config.wait_func(); in diskio_blkdev.c or the LCD hangs at while(!m_spi_xfer_done)  after calling nrfx_spim_xfer();

    Yes, this definitely sounds like a interrupt priority issue.
    What is the priority you are using for the interrupt handler which you would like to initialize the SPI instances from, and what is the priority of the SPI instances?
    The best illustration of this issue is how the LCD hangs on !m_spi_xfer_done - this is a flag which should be set as part of the SPI event handler ( on a TX / RX complete event ), but if the waiting occurs in an interrupt with a equal or higher priority than the SPI interrupt, the SPI interrupt will never get to process - because it is waiting for the interrupt that contains the SPI init to finish - and that interrupt will never finish, because it is waiting for the SPI event handler to toggle the flag.
    This is likely the cause of the deadlock you are seeing - its quite a common issue when working with different priority interrupts that depend on each other.

    The reason why everything works in you main context is because it has the lower priority, which means it will be interrupted by any interrupt regardless of priority level. Thus, whenever a interrupt (such as the SPI RX / TX complete event ) occurs, it is immediately processed. You can read more about the different interrupt priorities here.

    I think we will be able to resolve this issue as soon as we know what priority the different interrupts have in your application.

    Looking forward to resolving this issue together!

    Best regards,
    Karl

Children
No Data
Related