Author Topic: SPI Conflict between RFM69 and SD library  (Read 28756 times)

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6866
  • Country: us
    • LowPowerLab
Re: SPI Conflict between RFM69 and SD library
« Reply #30 on: February 16, 2016, 04:13:34 PM »
Man, nice clocks :)

Lensdigital

  • Full Member
  • ***
  • Posts: 155
    • Lensdigital
Re: SPI Conflict between RFM69 and SD library
« Reply #31 on: February 16, 2016, 06:07:23 PM »

Lensdigital

  • Full Member
  • ***
  • Posts: 155
    • Lensdigital
Re: SPI Conflict between RFM69 and SD library
« Reply #32 on: August 02, 2016, 10:27:49 PM »
Well I just wanted to report that "fix" didn't work in the long term. Lockups happen so randomly that sometimes it can take 2 weeks, and sometimes it happens 5 times a day. But when SPI locks up SD Card, only removing power fixes it (I tried using watchdog timers, but it didn't help)...
That obviously put my whole Xronos 3 project on hold until further notice. Recently I had some spare time to work on it again, and I'm going to see if I can modify RFM69 library to use SPI.beginTransaction and SPI.endTransaction methods which was added to Arduino SPI library recently...
OricDan I know you were talking about this from beginning, but I didn't understand it then :)
« Last Edit: August 02, 2016, 10:29:54 PM by Lensdigital »

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: SPI Conflict between RFM69 and SD library
« Reply #33 on: August 03, 2016, 07:31:01 AM »
FWIW, I'm becoming more and more convinced that an SD Card needs to be isolated from the SPI bus when it's not being accessed.  Level translator with enable should work.  And be sure to pull up key pins like SCK (or pulldown if you're using Mode0), MISO, MOSI, and the unused reserved pins on the Micro-SD side.

Tom

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: SPI Conflict between RFM69 and SD library
« Reply #34 on: August 03, 2016, 10:47:12 AM »
Has anyone tried the 470R resistor hack on the SD card's MISO signal? I've worked on systems where the SD card is shared and this was found to be necessary because some SD cards don't release MISO even with dummy clocks with CS# high.
Mark.

Lensdigital

  • Full Member
  • ***
  • Posts: 155
    • Lensdigital
Re: SPI Conflict between RFM69 and SD library
« Reply #35 on: August 03, 2016, 12:52:54 PM »
I haven't heard about 470R SD card hack. Might be worth a try. Pullup or pulldown?
Tom, thanks for the suggestion!  It might be a pain tho to add all these extra resistors, but I'll try with MISO...
Also have very similar devices (Xronos Clock 2) but it uses RFM12b instead of RFM69. Zero issues there (I've been making them for over 3 years now). I just do radio.sleep() before reading SD card.
Actually I'm going to try RFM12b on new boards as well (I made radio module plug-in so it can be easily swapped)...

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: SPI Conflict between RFM69 and SD library
« Reply #36 on: August 03, 2016, 01:06:20 PM »
No, I don't mean a pull-up on MISO. If the SD card does not release the MISO then adding a series resistor directly at the SD card's MISO output allows other devices to over-drive it (you wire the SD card MISO to a 470R resistor, then the other side of the resistor goes to the MCU MISO and the other device(s) MISO).
Mark.

Lensdigital

  • Full Member
  • ***
  • Posts: 155
    • Lensdigital
Re: SPI Conflict between RFM69 and SD library
« Reply #37 on: August 03, 2016, 03:27:00 PM »
Ah I see! Thanks!
BTW here's my RFM breakout. Works with both RFM12b and RFM69W and also can be connected to BT module. Very useful if you need to swap frequencies, etc...

« Last Edit: August 03, 2016, 05:16:31 PM by Lensdigital »

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: SPI Conflict between RFM69 and SD library
« Reply #38 on: August 03, 2016, 09:09:35 PM »
No, I don't mean a pull-up on MISO. If the SD card does not release the MISO then adding a series resistor directly at the SD card's MISO output allows other devices to over-drive it (you wire the SD card MISO to a 470R resistor, then the other side of the resistor goes to the MCU MISO and the other device(s) MISO).
Mark.
Mark, in my experience it's the SD card that gets hosed, not the rest of the SPI devices.  I would think the issue you've raised is more about messing up other device's transactions - unless I'm missing something.

I've found if you can keep the SD card operation atomic - Open the SD device, do your thing, close it without doing any other SPI device operation in the middle of this, your chance of success is much much better.  Additionally, I've not had much success with anything other than SDSC cards (on AVR platforms).

Tom
« Last Edit: August 03, 2016, 09:15:31 PM by TomWS »

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: SPI Conflict between RFM69 and SD library
« Reply #39 on: August 03, 2016, 11:43:58 PM »
Ah, OK. The scenario I had was that I produced a 'dongle' with an AVR and an SD card so that a customer could update an FPGA board in the field. The dongle interface had an SPI interface to the FPGA's serial flash. The problem was that the SD card refused to release MISO, so the dongle had trouble accessing the SPI flash. Adding a series resistor fixed it. In that case though I was doing full 512 byte bursts so the SD accesses were atomic.

Mark.

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: SPI Conflict between RFM69 and SD library
« Reply #40 on: August 04, 2016, 07:44:25 AM »
In that case though I was doing full 512 byte bursts so the SD accesses were atomic.
I've even tried that and failed.  It was only when I did SD.init(), Open file, write blocks, close file in one operation...

Tom

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: SPI Conflict between RFM69 and SD library
« Reply #41 on: August 04, 2016, 11:33:44 AM »
Interesting. I wonder if the SD library has an effect (specifically dummy clocks and cleanly starting/stopping things). I use FatFs, or for simple things PetitFs. I used to use EFS but that was bloated and bug ridden. I've never had any problems with PetitFs:
http://elm-chan.org/fsw/ff/00index_p.html
Mark.

Lensdigital

  • Full Member
  • ***
  • Posts: 155
    • Lensdigital
Re: SPI Conflict between RFM69 and SD library
« Reply #42 on: August 04, 2016, 12:37:19 PM »
FYI I'm using SD Library that's part of WaveHC library (by Adafruit). Not sure how to integrate another one.
For now I'm going to see if I can resolve this issue in software. I finally ported my code to work with Both RFM12b and RFM69. Had to build RFM12b weather sensor and so far it's working... But time will tell.
I hope it locks up, then I can try hardware solution (resistors)....
BTW if anyone interested to write code for both modules, it's quite easy, just use defines..
Code: [Select]
//#define RFM69_CHIP // Comment out for RFM12b
#if defined (RFM69_CHIP)
  #include <RFM69.h>
#else
  #include <RFM12B_arssi.h>
#endif

#if defined (RFM69_CHIP)
  RFM69 radio;
#else
  RFM12B radio;
#endif

... and so on...
« Last Edit: August 04, 2016, 12:39:19 PM by Lensdigital »

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: SPI Conflict between RFM69 and SD library
« Reply #43 on: August 04, 2016, 05:26:04 PM »
Interesting. I wonder if the SD library has an effect (specifically dummy clocks and cleanly starting/stopping things). I use FatFs, or for simple things PetitFs. I used to use EFS but that was bloated and bug ridden. I've never had any problems with PetitFs:
http://elm-chan.org/fsw/ff/00index_p.html
Mark.
Thanks for the links, Mark.  I'll try them out.  I've been using SD_Fat so this might be a worthwhile change.

Tom

XFVB56

  • NewMember
  • *
  • Posts: 2
  • Country: us
Re: SPI Conflict between RFM69 and SD library
« Reply #44 on: September 20, 2016, 08:36:20 AM »
Well I just wanted to report that "fix" didn't work in the long term. Lockups happen so randomly that sometimes it can take 2 weeks, and sometimes it happens 5 times a day. But when SPI locks up SD Card, only removing power fixes it (I tried using watchdog timers, but it didn't help)...
That obviously put my whole Xronos 3 project on hold until further notice.
Hi, I'm new here.  This  reminded me of a similar problem that hung me up for weeks on a design job a number of years ago. SPI is designed to support bus sharing, but as soon as you add interrupts to the mix things get complicated.  Without (even with!) a real time debugger and a logic analyzer it can be very hard to solve hardware bus contention problems. You might try to divide and conquer. Create a  software bit-banged SPI port to drive one of the SPI devices, and use the hardware port to drive the other.   If you drive the Software SPI port with an ISR routine it won't take all that much CPU time. If that's not fast enough, you could change hardware to a CPU that has more than one hardware SPI port. You can get "official" Arduino software support using the same processor that's in the Arduino Zero and the Adafruit Feather M0. That is the ARM Cortex M0 part # ATSAMD21G18.  It has a ton of memory and most important for your design,  six hardware communications ports. Any of these can be used as a UART, I2C, or SPI port.