In testing my application I have noticed a problem with the SPI bus use when WiFi is on but the WAP for the stored credentials is not available (switched off or out of range). I can repeat the issue which manifests as the application thread blocking if the SPI bus is used approximately 70 seconds after a restart.
I have Log traced the issue to be in a function which reads an image file (.bmp) from SD card and writes to a TFT screen. This action involves having a file open and repeated reads to a buffer and then writes to the TFT screen pixel by pixel. There is a lot of activity on the SPI bus. There is no memory issue. The application hang is ‘caught’ by the application watchdog, the trace and memory captured and the device restarted.
The application will hang approximately 70 seconds after restarting - SYSTEM_THREAD(ENABLED) and SYSTEM_MODE(SEMI_AUTOMATIC). The photon LED will be flashing green throughout, the system thread is not impacted. The device has valid credentials but the WAP for those credentials is turned off when restarted - WICED returns 1024 error. All calls to blocking Particle cloud functions are surrounded by tests for Particle.connected().
The cause of the hang appears to point to an SPI bus issue - can anyone help with any experience and whether this can be caught and corrected or indeed this theory can be confirmed? Reducing the SPI speed appears to solve the problem - need to do more testing though to be sure.
Did you ever get to the bottom of this? I’m fighting occasional corruption in an SPI read (sometimes takes 3 days of continuous operation to show itself) and wondering if it might be related. In my case, the hang occurs because the particular version of the SdFat library I’m using gets stuck in a loop inside FatVolume::freeChain, reading the same invalid/self-referencing cached cluster over and over again. I’m switching to (pending testing) the latest version of https://github.com/greiman/SdFat which flags this particular case as a fatal error, but that doesn’t address the root cause of the corrupted SPI read.
The workaround for this problem was to reduce the speed of SPI bus to half speed (for both the SD card and TFT). I have also recently moved to the latest version (1.0.16) of this library (I was using 0.0.7 when I posted the above) and until I updated about 2 weeks ago.
There have also been a few changes in Device OS in the WiFi area and with WICED. Since upgrading the library and device OS I haven’t noticed any reoccurrence.
Regards the SPI read corruption - I have quite a few checks to ensure that a reset does not occur whilst a write is in progress. Maybe this isn’t what you are seeing - credit to you for tracking it down to a module and cause. I have seen failures in the SD card controllers and also connection issues with the contacts especially in environments with large swings in temperature and humidity.
Thank you, good to know you found a path forward and aren’t seeing problems anymore. I’m evaluating version 1.1.0 of the SdFat library and so far it seems pretty stable. And thank you for the tip on sdcard controller and contact failures, definitely a possibility.