I am using the DC 10.72 SPIRead library function to read out the temperature and humidity from a device. After several tens of thousands of readings (sometimes less iterations, sometimes more) the program hangs in the SPIRead function.
Anyone have this issue and solution?
The default settings (which I am using) are on Port B. PB0 is used for the serial flash clock. Possible conflict and source of my hang?
The problem appears to be the library using Serial Port B with the clk on PB0. I hooked up a scope and saw clock activity on the line even with my SPI routine disabled. Something else is periodically clocking 2 bytes. The literature says the serial flash uses the line at INIT, but not after. Something is using it though. I wrote a bit-bang routine and used PB4 for the clock, works like a champ now.
What product was this? There are a few SPI-related bug fixes in the GitHub repository:
https://github.com/digidotcom/DCRabbit_10/commits/master
If you make use of the UserBlock on products that boot from a serial flash, they will access the SPI bus.
Dynamic C 10.72 and RCM 5650. To my knowledge, I am not using User Blocks, but perhaps the WiFi routines are accessing calibration data?
Is there an ADC on the 5650? Take a look at the schematic and you should be able to see what devices are on the SPI bus and might be in use. And you could just make use of the SPI semaphore in your own code to ensure that there aren’t any SPI conflicts. Just make sure you have the semaphore before asserting chip select on your device.
Looking at the schematic at http://ftp1.digi.com/support/documentation/0900280_f.pdf
There is an ADC also connected to the SPI interface so using the semaphore would be a must.