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

iamatesla

  • Newbie
  • *
  • Posts: 2
  • Country: us
Moteino Power Up Problem
« on: February 24, 2016, 10:22:18 AM »
Ok, so I've been battling a very annoying problem for a while now.... my Moteino will not start up when power is applied.

I'm running a simple receive sketch and I know the code works. I apply power and 10% of the time the Moteino will turn on, blink the onboard LED with the bootup sequence, and operate properly. The other 90% of the time it does nothing when power is applied. The only consistant way to make it function is to apply power and then momentarily short reset to ground. For my application, I need it to start up on power application every time.

I have tried applying 5V to the Vin pin to power it with multiple power supplies including a nice bench supply. I have tried applying 3.3V directly to the 3.3V pins with the bench supply. There appears to be no difference in the result. I can post code if it could be a problem. Are there any simple tricks or dumb things I could be doing?

Thanks!




TomWS

  • Hero Member
  • *****
  • Posts: 1926
Re: Moteino Power Up Problem
« Reply #1 on: February 24, 2016, 10:39:14 AM »
Ok, so I've been battling a very annoying problem for a while now.... my Moteino will not start up when power is applied.

I'm running a simple receive sketch and I know the code works. I apply power and 10% of the time the Moteino will turn on, blink the onboard LED with the bootup sequence, and operate properly. The other 90% of the time it does nothing when power is applied. The only consistant way to make it function is to apply power and then momentarily short reset to ground. For my application, I need it to start up on power application every time.

I have tried applying 5V to the Vin pin to power it with multiple power supplies including a nice bench supply. I have tried applying 3.3V directly to the 3.3V pins with the bench supply. There appears to be no difference in the result. I can post code if it could be a problem. Are there any simple tricks or dumb things I could be doing?

Thanks!
Try shorting the DTR & GND pins on the FTDI connector.  If you're not using an FTDI cable, this has solved this problem in some cases.

Tom

iamatesla

  • Newbie
  • *
  • Posts: 2
  • Country: us
Re: Moteino Power Up Problem
« Reply #2 on: February 24, 2016, 01:01:59 PM »
Well .... that appears to have solved the problem!

Not sure why exactly... the Moteino schematic appears to handle the RST to DTR connection the same way a regular arduino does...

Anyway, thanks a ton Tom!
« Last Edit: February 24, 2016, 01:12:58 PM by Felix »

Rawze

  • Newbie
  • *
  • Posts: 7
  • Country: us
Re: Moteino Power Up Problem
« Reply #3 on: December 01, 2016, 09:38:32 PM »
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 ...
Code: [Select]
...
 unsigned long start = millis();
  uint8_t timeout = 50;
  do writeReg(REG_SYNCVALUE1, 0xAA); while (readReg(REG_SYNCVALUE1) != 0xaa && millis()-start < timeout);
...
 

to ...

Code: [Select]
...
  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.
« Last Edit: December 01, 2016, 10:20:50 PM by Rawze »

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: Moteino Power Up Problem
« Reply #4 on: December 02, 2016, 06:23:31 AM »
I've always maintained that the RFM69 has an open source reset structure with an internal pull-down (unlike the RFM12B that has an open drain structure with an internal pull up). This allows the RFM69 itself to drive its own reset line high for the duration of its power up reset time, and also allows external devices to reset it cleanly. Ideally the processor should be able to read this reset line and be able to drive it with an open source driver, but this pin is not connected on the Moteino.

Connecting DTR to GND with no cable connected effectively adds a 100nF capacitor to GND across RST which acts like a reset delay. So maybe the solution is simply to add a delay at the beginning if radio.initialize() sufficient to allow the RFM69 to complete it's power up reset cycle. The SUT fuses are already blown for slow rise time supply but this may not be sufficient time for the radio, but adding the 100nF cap across RST delays the reset enough.

Mark.

Rawze

  • Newbie
  • *
  • Posts: 7
  • Country: us
Re: Moteino Power Up Problem
« Reply #5 on: December 02, 2016, 07:19:43 AM »
I've always maintained that the RFM69 has an open source reset structure with an internal pull-down (unlike the RFM12B that has an open drain structure with an internal pull up). This allows the RFM69 itself to drive its own reset line high for the duration of its power up reset time, and also allows external devices to reset it cleanly. Ideally the processor should be able to read this reset line and be able to drive it with an open source driver, but this pin is not connected on the Moteino.

Connecting DTR to GND with no cable connected effectively adds a 100nF capacitor to GND across RST which acts like a reset delay. So maybe the solution is simply to add a delay at the beginning if radio.initialize() sufficient to allow the RFM69 to complete it's power up reset cycle. The SUT fuses are already blown for slow rise time supply but this may not be sufficient time for the radio, but adding the 100nF cap across RST delays the reset enough.

Mark.

Thanks for the info. I hadn't looked at the schematic to see that yes,  shorting the DTR line is essentially doing the same thing that i did,.. but on my Mega with the built in usb port, the DTR line is not exposed from what I can tell. As well,.. i tried exactly what you described long before resorting to a capacitor. I tried delays up to 10 seconds before the init routine, etc... and it made no difference in the amount of inconsistencies I was getting.

No disrespect to the designer, but personally, I think the devices should have an instruction sheet/recommended connection diagram or something supplied with them to lessen the initial learning curve. It took me an entire day of myself, and a friend searching the Internet and scratching our heads when I got my first one, just to figure out that with the flash ram option, they require a 10k ohm resistor from 3.3v to the control pin of the SPI flash ram pin before I could send a sketch to one for the first time. If I had known that it is recommended to use this resistor, and that the reset line needed extra delay with a capacitor (DTR pin shorted etc, whatever method), when operating stand alone, then It would have gone much smoother form the start.

These things seem to be really great, Well built, devices at a very reasonable price. The potential these things have is scary wicked cool for wireless automation control. I see lots of potential that I am certainly going to take advantage of with them. I am getting ready to buy several more, as the 6 I have are already assigned to something.   :D  -- I even have a touch screen on order for one of my mega units so it can be used as a hand-held remote to control other units.
« Last Edit: December 02, 2016, 07:40:42 AM by Rawze »

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6404
  • Country: us
    • LowPowerLab
Re: Moteino Power Up Problem
« Reply #6 on: December 02, 2016, 09:40:15 AM »
For the record - the current fuse settings are set to wakeup the chip after 256k cycles + 65ms.

TomWS

  • Hero Member
  • *****
  • Posts: 1926
Re: Moteino Power Up Problem
« Reply #7 on: December 02, 2016, 09:44:27 AM »
Interesting.  @Rawze, I'm glad you pursued this enough to isolate the problem to the radio not initializing properly (I had incorrectly assumed it was the POR circuit on the Atmel part).   This is very plausible as the times I've had issues are mostly when I get power line spikes that probably reset the processor but leaves the radio in some ugly state. 

I have wired the radio reset pin on some of my motes but haven't really taken advantage of that.  Perhaps I should...

Thanks again for digging into this.

Tom

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6404
  • Country: us
    • LowPowerLab
Re: Moteino Power Up Problem
« Reply #8 on: December 02, 2016, 10:21:15 AM »
when I get power line spikes that probably reset the processor but leaves the radio in some ugly state

Tom - what kind of spikes are we talking? Transients? During storms or just random spikes from a less than great neighborhood transformer?
How does that translate into affecting the Moteino reset? EMI induced or just via power supply spikes?
Other than adding circuitry or changing the Moteino - could this type of scenario be improved in other ways?

TomWS

  • Hero Member
  • *****
  • Posts: 1926
Re: Moteino Power Up Problem
« Reply #9 on: December 02, 2016, 11:58:40 AM »
Tom - what kind of spikes are we talking? Transients? During storms or just random spikes from a less than great neighborhood transformer?
How does that translate into affecting the Moteino reset? EMI induced or just via power supply spikes?
Other than adding circuitry or changing the Moteino - could this type of scenario be improved in other ways?
In my 'neighborhood', which is in the woods, it seems that any time the wind speed is over 5MPH (I may be exaggerating about this low speed), we get power line dropouts and spikes.  It wreaks havoc on any line powered devices. 

But, as far as powering on Motes, I've seen a 'non-reset' condition simply installing the battery.  Now that I think about it, in these cases I've been able to notice that the unit didn't start up because I didn't see the usual bootloader LED flash sequence.  Hmmmm...

In any case, ALL my current and future Motes will have TPL5010s (or TPL5110s) added to the base design and, after Rawze's tests, I'll probably add the RFM69 reset to all Motes with radio...

Tom

joelucid

  • Hero Member
  • *****
  • Posts: 867
Re: Moteino Power Up Problem
« Reply #10 on: December 02, 2016, 12:10:32 PM »
Quote
what kind of spikes are we talking?

I have such a spike problem myself: I used to get hanging moteinos from time to time, esp with cheap power supplies. One day it was so bad that I could measure it with the scope: I saw a clear spike down in voltage at Vin, lasting a couple of ms, drawing power down to around 2.5V and triggering BOD (using a 5V power supply!). For whatever reason the Moteino would just hang then.

At first I just switched off the BOD and this mostly fixed it. Still got it once again though a few weeks back and now I added fat bulk caps at Vin. Haven't had the problem since which doesn't mean much since it was so rare. I should probably add a diode to prevent the cap from being drained into the power supply on a down spike.

Joe


joelucid

  • Hero Member
  • *****
  • Posts: 867
Re: Moteino Power Up Problem
« Reply #11 on: December 02, 2016, 12:24:19 PM »
Quote
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.

Hard to figure out what's really going on here: the reset pin is not connected to the radio. The 328p does get a clean reset - otherwise it couldn't blink the LED. How could a short delay in starting up the 328p (via a delayed reset) allow the radio to power up more cleanly?

I have only one theory: the 328p draws much less power during reset than when running. So if Vin isn't stable initially (e.g. some sort of bouncing) that leaves more power for the radio. Maybe the radio can get stuck if power isn't stable enough during startup.

Joe

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: Moteino Power Up Problem
« Reply #12 on: December 02, 2016, 12:40:38 PM »
I was confused by this too Joe, I assumed the radio was being accessed before its power up sequence had finished but apparently adding a software delay in the code before initialization made no difference. Delaying the real reset though keeps the processor's I/O tristated for longer, maybe that causes some problems but it's all a bit odd.

Mark.

odiephd

  • Newbie
  • *
  • Posts: 36
  • Country: us
Re: Moteino Power Up Problem
« Reply #13 on: February 26, 2017, 02:12:03 PM »
I just bought several RFM69HW's, and the first one built is having this issue when powering from 9V battery.  I shorted DTR and GND with short wire and it worked once.  I am not as familiar with the inter-workings of the Motes, but I love them!   

What is the final resolution to this problem?

Thanks
Jim

odiephd

  • Newbie
  • *
  • Posts: 36
  • Country: us
Re: Moteino Power Up Problem
« Reply #14 on: February 26, 2017, 05:13:29 PM »
Ok, I tried the 0.1 uf cap across RST to GND, the onboard LED blinks a couple times then stays solid for a second.  That's it.

Still works fine through FTDI connector to computer USB.

joelucid

  • 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 (https://lowpowerlab.com/forum/moteino/moteino-will-not-run-until-reset-has-been-jumped-with-ground/msg17700/#msg17700) 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?

Joe

odiephd

  • Newbie
  • *
  • 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.


Rawze

  • Newbie
  • *
  • 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...

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.
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
#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.

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

Felix

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