Hi All-
I’ve been working on a board that interfaces with a Boron to take measurements and save data to an SD card. The firmware uses the SDFAT library and I’ve attached an image of the SD card section of the schematic to this post showing how the SPI port is used for the SD card. The firmware collects data from the sensors, writes to the SD card, and then delays for 0.1 second, and then does it all over again. This has worked well for a few months, but as we expand testing to the field there have been some inconsistent failures.
The system will flag an SD failure at (as yet) unpredictable times. Sometimes the failure will fix itself, sometimes the failure will persist despite cycling power or resetting the unit. We have multiple units; when the failure occurs on Board A and Boron A but does not fail on Board B and Boron B, we can swap the Borons so the failure follos the boron (Where Board B and Boron A continues to fail).
Question 1: Has anyone had issues similar to these? Could we be missing anything?
I am working remotely to troubleshoot the error on my bench and only have 1 unit. My unit does not exhibit a failure, however I attached my 4-ch scope to look at the signals, and found that while it starts OK, the clock signal becomes a ‘runt’ and while the system still seems to work, the signal is concerning. I am attaching a scope shot showing the first write to the SD card that starts out well, but then the clock delivers runt signals.
Question 2: Has anyone seen anything like this? What, if any, conclusions could be drawn from this scope shot? I have another Boron on the way to test if I have a damaged unit.
We are at the early stage of troubleshooting a problem that so far this week has decided not to show up. I would be open to any suggestions or ideas!
Thanks,
Dave
I don’t really have an explanation for this, however it would be useful to see if 2.0.0-rc.3 makes a difference.
The IO pins on the nRF52 can run in two modes: standard drive and high drive. In 2.0.0-rc.3 the SPI port was changed to default to high drive instead of standard drive. In older versions, all IO always used standard drive mode.
It’s not clear that that’s the problem, but it would be an interesting data point.
Thanks Rick for your help! I tried updating the OS to 2.0.0-rc.3 and got the same result :(.
I’ve been testing different things, and have found that the first instance of the SS pin going low to communicate with the SD card works great, but the second and subsequent times, it has the runt SCK signal. I’m attaching a scope shot to show this. Also, I’ve chopped the code down to just work with the SD card and nothing else. Here is a very generic app that still shows the failure; do you see anything unusual? https://go.particle.io/shared_apps/5f998f0ce6f0b000092af1e5
Another interesting piece of data is that if I keep the SD card removed, the SCK signal remains normal as it occasionally pings for a SD card. If I start the system with the SD card removed and hot-plug the SD card in, the runts start on the second SS assertion. If I then hot-remove the SD card, the SCK signal remains distorted/runt even after the SD card is removed.
On a hunch I tried adding a 100 ohm resistor in series with the SCK line with no change seen. Would you have any ideas for what could be going on, or things to try?
I have experienced one brand of SD card not work with Boron + SdFat and then another brand work. Try a diversity of microSD cards to rule that out. I’m pretty sure it was a Samsung PRO Endurance which didn’t work for me whereas the typical read/grey SanDisk worked.
I don’t have any series resistors.
I hookup a Sparkfun SD card module straight to the correct pins on Boron.
One positive thing I can say about Boron is that I haven’t had any SdCard-interfacing issues with it.
Thanks Paul!
I’ve checked 2 different vendors (Sandisk Ultra red/grey and some generic, maybe Lexar?). But the next time I’m out I’ll pickup anther SD card.
I’m still working my original problem; not sure what my next step is.
Hi All-
I’ve been working on the problem more and have some more data to report, if anyone has ideas on what else could be done.
I loaded the firmware onto an Arduino Due that I had (with Particle.publish commands commented out) and connected it to my PCB with breadboard wires (since the headers were designed for the Boron). I monitored the SD card signals with my scope. The Due was able to send a normal set of SPI signals repeatedly (no SCK runt signals like from the Boron).
I tried changing my code to use Half Speed and Quarter Speed (while (!sd.begin(chipSelect, SPI_FULL_SPEED)) {) but that didn’t compile in the Web IDE (It did compile in Arduino with my Due setup). I’m not sure what could be the issue there, it gave me an error of lib/SdFat/SdCard/SdInfo.h:116:37: ‘F_CPU’ was not declared in this scope. I’m not sure of how to address this.
I commented out everything in the code except the while (!sd.begin(chipSelect, SPI_FULL_SPEED)) { initialization code, and the runts continued to appear the second time the SS pin went low.
Instead of using the SPI_HALF_SPEED macro just use the numeric frequency value. The constant that describes the CPU clock is not defined for Particle devices.
Thanks for the heads up on the speed change! That helped me a great deal. I now understand what is going on!
After changing the speed to slow things down, I realized that there were 2 speeds in play. The system initially starts out as 250kHz (which I was able to see just fine on my scope) and then changes the speed to whatever is configured by the code. The standard SPI_FULL_SPEED with the Boron happens to be ~33MHz. I had bandwidth limit set on my scope which caused the 33MHz signal to appear as runts. An embarrassing measurement error – I should have known to open up the bandwidth…
