nRF52840 SPI init hangs after event loop starts

[poolshark021]

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

[Karl Ylvisaker]

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

[poolshark021]

I think I solved my interrupt issue with info from this topic:

https://devzone.nordicsemi.com/f/nordic-q-a/49732/spi-sd_app_evt_wait-and-nested-interrupts

I decided to only use the event handler to set a flag and then let the interrupt return.  Then I circle back and handle the flag and data transfer afterwards. 

I'm still getting hard faults but it's not related to the interrupt issue.  I'm hitting V7M Exception breakpoints for ExceptionEntryReturnFault and HardFault.  I have the hardfault handler enabled but I don't ever see it getting used.  I have DEBUG and DEBUG_NRF defined.  No info is displayed in the log (using RTT backend).

I am currently stepping through code leading to the hard faults.  If I can pinpoint where its happening I will update this thread

[Karl Ylvisaker]

Hello,

poolshark021 said:

I think I solved my interrupt issue with info from this topic:

I am happy to hear that you have resolved your issue!

poolshark021 said:

I decided to only use the event handler to set a flag and then let the interrupt return.  Then I circle back and handle the flag and data transfer afterwards. 

This is a good way of implementing this, especially if it is not paramount that the flag event is processed immediately(since the main context has the lowest priority). Good choice!

poolshark021 said:

I have DEBUG and DEBUG_NRF defined.  No info is displayed in the log (using RTT backend).

By this, do you mean that you are not seeing anything at all written out to your RTT backend, or only that you are not seeing any error messages despite having DEBUG defined?

poolshark021 said:

I am currently stepping through code leading to the hard faults.  If I can pinpoint where its happening I will update this thread

Be advised that you can not step through the code when the SoftDevice is active, as this will halt the CPU - causing the SoftDevice to miss its timing-critical tasks, and thus crash. If you are debugging a peripheral I recommend disabling the BLE parts of the application before stepping through the code.

Best regards,
Karl

[poolshark021]

My RTT log window gets <DEBUG>, <INFO>, etc messages during normal operation, just not until my while loop executes and NRF_LOG_PROCESS() is called.  However when I had a hard fault I would not get any info on the logger screen at all.  I tried to implement the hardfault_handler by adding hardfault_handler_gcc.c to my project and enabling it in sdk_config.h, but nothing changed.

I ended up using a bunch of breakpoints and code stepping to figure out the hard fault was because I was adding too big of an array to the stack.  I never once hit the hardfault breakpoint and never got any info displayed about it.

My original problem is now solved, however I would like to see the hardfault handler working for future use.  Do I need to do anything else besides add the correct handler file and enable it in sdk_config.h?  

[Karl Ylvisaker]

poolshark021 said:

My RTT log window gets <DEBUG>, <INFO>, etc messages during normal operation, just not until my while loop executes and NRF_LOG_PROCESS() is called.

Thats great, thank you for clarifying.
NRF_LOG_PROCESS must be called when using the DEFERRED logging option - this allows you to control when log processing will happen, so that it minimally affects the performance of the application during development. For example, if you are doing a time-critical task, and a lot of logging, it would be unfortunate to use in-place processing.
You can read more about the logger module library here.

poolshark021 said:

I ended up using a bunch of breakpoints and code stepping to figure out the hard fault was because I was adding too big of an array to the stack.  I never once hit the hardfault breakpoint and never got any info displayed about it.

It sounds to me like your hardfault handler is not enabled / implemented properly.
Please have a look at this blogpost about error handling with the nRF5 SDK.
If this does not remedy your issue, please open a new ticket forum, since this is diverging from the original topic.

poolshark021 said:

My original problem is now solved, however I would like to see the hardfault handler working for future use.  Do I need to do anything else besides add the correct handler file and enable it in sdk_config.h?  

I am happy to hear that your original problem is now solved!
For future reference I would ask that you open a new ticket for this new issue, since it is diverging from the original topic in this ticket - this will keep the forums tidy, and easier to navigate for other users. :)

Please do not hesitate to open a new ticket if you should encounter any other issues or questions during your development!

Best regards,
Karl