Author Topic: Moteino Power Up Problem  (Read 4776 times)


  • Hero Member
  • *****
  • Posts: 867
Re: Moteino Power Up Problem
« Reply #15 on: February 27, 2017, 02:26:52 AM »
There was recently a long discussion on this topic ( with two resulting suggestions: testing a pull-up on MISO to work around a potential bootloader problem and trying a pull-up on SCK.

Could you try these?



  • NewMember
  • *
  • Posts: 36
  • Country: us
Re: Moteino Power Up Problem
« Reply #16 on: February 27, 2017, 03:38:36 PM »
More Info:

I powered up the mote with temp/hum SHT31 sensor using the FTDI/USB connector to my computer, and confirmed it was working.  I connected the battery and quickly removed the FTDI connector and it continues to work. 

I disconnect the battery, wait a few seconds and reconnect, but it doesn't work.  No blinking at all.


  • NewMember
  • *
  • Posts: 7
  • Country: us
Re: Moteino Power Up Problem
« Reply #17 on: May 28, 2017, 07:01:20 AM »
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...

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.
Code: [Select]

#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

void setup()
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.

« Last Edit: May 28, 2017, 07:43:45 AM by Rawze »


  • Administrator
  • Hero Member
  • *****
  • Posts: 6620
  • Country: us
    • LowPowerLab
Re: Moteino Power Up Problem
« Reply #18 on: June 07, 2017, 12:15:37 PM »
Good analysis and findings, thanks for sharing this.