I have a board with both Ethernet2 and RFM69 hardware. It has been locking up after a few minutes of operation, and I've finally tracked down the problem.
The RFM69 driver uses SPI in interrupt context. If the Ethernet2 driver is in the middle of a SPI transaction at the moment that an RFM69 interrupt hits, then the Ethernet2 SPI transaction is corrupted. This results in the SPI interface locking up, and the application freezes.
I made the following simple change:
@@ -106,6 +106,7 @@ bool RFM69::initialize(uint8_t freqBand, uint8_t nodeID, uint8_t networkID)
if (millis()-start >= timeout)
return false;
_inISR = false;
+ SPI.usingInterrupt(_interruptNum);
attachInterrupt(_interruptNum, RFM69::isr0, RISING);
selfPointer = this;
This fixes the problem and completely eliminates the lockup.
The fix is available here: git@github.com:stevefalco/RFM69.git
Please review and merge it.
There is a larger additional change that should be made. In particular, the RFM69 library should be using SPI.beginTransaction() and SPI.endTransaction(). This is necessary for the RFM69 library to respect other SPI devices that wish to use interrupts.
In other words, SPI.usingInterrupt() declares your desire to use SPI in interrupt context, whereas SPI.beginTransaction() and SPI.endTransaction() perform the actual interrupt enable/disable operations. For proper cooperative behavior, both sets of calls should be used by all SPI device drivers.