I don't know about others, but the several R4 and Mega units that I have had now for a couple weeks, seem to have a very similar problems.
I have had very similar issues with Power-up of the Moteino R4 and the Mega's that I have here. I think they are fantastic devices, but I have seen some inconsistencies on startup with them when using V-IN power to them stand alone with USB chargers and/or batteries. The inconsistency happens when the power is applied and they are stand alone. It seem that the RFM69 does not always get a full reset during power-up from what I can tell, and it seems to get worse when there is a bit low battery, but enough to run it.
To catch this in action, I added an additional "catch/fail" line to the initialize() routine in the RFM69 library upon "first contact" to the unit from the library.
I added a line of code just past here ...
...
unsigned long start = millis();
uint8_t timeout = 50;
do writeReg(REG_SYNCVALUE1, 0xAA); while (readReg(REG_SYNCVALUE1) != 0xaa && millis()-start < timeout);
...
to ...
...
unsigned long start = millis();
uint8_t timeout = 50;
do writeReg(REG_SYNCVALUE1, 0xAA); while (readReg(REG_SYNCVALUE1) != 0xaa && millis()-start < timeout);
//Fail the init routine if timed out/still not 0xaa.
if( readReg(REG_SYNCVALUE1) != 0xaa ) { return false; }
...
The reason for this is that there is no exit with fail test for the very first exchange of info on the SPI to the the RFM69.
In my calling program, if the init fails, I resort to blinking the on-board LED rapidly (80 ms blink rate) and halting the entire sketch. This way I will know for sure if I have a bad boot sequence and the device is NOt going to communicate properly.
================
What was happening for me is while they were connected to the FTDI (R4), or the usb directly (Mega with usb on board), they worked flawlessly and perfectly, but put them on a separate power source,... they have trouble. With my sketch set to blink rapidly on init failure, powering the devices up via plugging them into a battery several times over reveals that at least for me, they do fail the init randomly.
I suppose someone with no error checking at the init routine failure would get very frustrated and scratch their head if this were happening to them. At first, I blamed it on all kinds of stuff in the Sketch I had made. Why would they not work unless connected to my PC?. - I even blamed it on the Serial etc,.. but in the end I found out what fixed it for me. It had nothing whatsoever to do with the sketch, or its libraries. It was a hardware problem, where the reset pin was not being held low long enough for both devices to reset properly when powered only by the VIN and no other connections. I didn't want to spend all night trying to find the exact value capacitor, etc. and simply wanted to prove my theory,.. so I pulled an old small (0.1uF) capacitor out of a bad circuit board i had laying around, tested it to make sure it was good, then placed it across the the reset pin to ground. -- VIOLA!!! --- 100% perfect boot sequence every single time I applied power to them.
I ended up just placing the capacitor on all my boards when they operate stand alone, and removing it when connected to the pc and it has completely solved the random boot issue I have been seeing with them. Nice big fat reset signal no matter how low the battery level might be.
I know I should take the time to eventually go find the correct value to use, but this does it for me so far no problem. I just unplug the capacitor before plugging the board back into the Pc for re-flashing for now.
Well, I have re-visited this problem and have found a solution. First of all the problem is 2-fold...
- The first is a fairly rare hardware problem when the flash ram is installed. This is pin #8 on the R4 and pin #23 on the Mega. The cs pin for the flash is missing a pull-up resistor. Most of the time this is not a problem, but it causes an occasional random problem with startup. Whenever the flash memory is installed, it requires a 10k ohm resistor on the cs pin for it. This solves random issue #1.
- The second, bigger and more pronounced problem that I originally somewhat solved with the capacitor on the reset line (also shorting out DTR to ground when not using the FTDI works too) is a problem created in the SPI buss during boot of the AVR. In section 7.2 of the RFM69 manual, it shows that after a reset (or power on reset) it takes approx 10ms for the device to become ready. What must be happening (guessing here) during this first 10ms, is that the RFM is having problems randomly with the state of the SPI buss, as it is in an unknown state. It is easily solved with software by simply driving the entire buss low (high works too, but low seems to be preferred) during this first 10ms period. Here is what I do to make them boot flawlessly every time...
SOLUTION:
1) Install/solder a 10k-ohm resistor between pin 8 (pin 23 on the Mega) and 3.3v if the flash memory installed. I solder this right to the board so that it is there permanently.
2) I then use the following code at startup of the AVR so that the SPI is held in a known state for at least a 10ms period at powerup before doing anything else.
#if defined(__AVR_ATmega328P__)
#define USING_MOTEINO_R4 //Assume this is an R4.
#define MOTEINO_LED_PIN 9 //onboard LED
#define FLASH_CS_PIN 8 //Flash cs pin.
#define RFM_SS_PIN 10 //RFM69 Select pin.
#define RFM_MOSI_PIN 11 //SPI mosi pin.
#define RFM_MISO_PIN 12 //SPI miso pin
#define RFM_SCK_PIN 13 //SPI SCK pin
#elif defined(__AVR_ATmega1284P__)
#define USING_MOTEINO_MEGA //Assume this is a Mega.
#define MOTEINO_LED_PIN 15 //onboard LED
#define FLASH_CS_PIN 23 //Flash cs pin.
#define RFM_SS_PIN 4 //RFM69 Select pin.
#define RFM_MOSI_PIN 5 //SPI mosi pin.
#define RFM_MISO_PIN 6 //SPI miso pin
#define RFM_SCK_PIN 7 //SPI SCK pin
#endif
void setup()
{
pinMode(RFM_MOSI_PIN, OUTPUT);
pinMode(RFM_MISO_PIN, OUTPUT);
pinMode(RFM_SCK_PIN, OUTPUT);
delay(10); //wait 10ms for the RFM69 to initialize.
// ... The rest of whatever boot code you are using to init the device.
Basically, drive all the SPI pins LOW and wait for 10ms before continuing with the sketch. I will continue to test this, but so far, all of my devices are running fine with this fix. Driving all the pins low in the buss sets it to a known state that the RFM69 can safely ignore during its startup. I tried using resistors both pull-up and pull-down but this did not completely solve the issue. Driving the pins with logic low seems to work the best.