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

[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