next topic »

[on:]

Hello,

I am selling some Arduino units programmed for a specific task. Some of my customers unintentionally abuse the Arduinos and this messes them up. The units are fine but they need to have the sketch uploaded again on the Atmegas in order for them to work. This is quite expensive and it takes a lot of time for shipping them back and forth.

Is there a way to enable trough the code some protection measure like shutting down the Atmega after a certain period of time? Or ending the sketch? Or entering in some kind of safe mode?

[Reply #1 on:]

This is quite expensive and it takes a lot of time for shipping them back and forth.

Send them an expensive bill, they will learn i the end

Is there a way to enable trough the code some protection measure like shutting down the Atmega after a certain period of time? Or ending the sketch? Or entering in some kind of safe mode?

yes, yes, no but I doubt if that is what you need (all disclaimers apply)

Your requirements are too unclear to give definitive answers especially for commercial projects - incomplete and wrong answers costs money too you know

So tell us more about what you want to protect.   (and remember there is no 100% protection ever)

[Reply #2 on:]

Send them an expensive bill, they will learn i the end

Is there a way to enable trough the code some protection measure like shutting down the Atmega after a certain period of time? Or ending the sketch? Or entering in some kind of safe mode?

yes, yes, no but I doubt if that is what you need (all disclaimers apply)

Your requirements are too unclear to give definitive answers especially for commercial projects - incomplete and wrong answers costs money too you know

So tell us more about what you want to protect.   (and remember there is no 100% protection ever)

The expensive bill scenario is not really an option. In fact I am a little embarrassed even though the unit breaks down when used in conditions that have nothing to do with normal use. I was hoping I made something fool proof.

It's a sort of ballistic chronograph for slowish projectiles, not bullets . The problem appears when it is accidentally left ON for many hours or even days (weekend). People forget to turn them OFF. When the Arduino is turned on, the chronograph starts automatically. If it's not stopped it keeps working.  Somehow this does something to the Atmega and the unit won't work. If I reinstall the sketch, it works fine.

I don't really know what is happening with the sketch. I don't know if the problem is the actual time the unit is turned ON or the fact that the battery drains out and after some hours the voltage drops so much that it messes up the Atmega.

I am looking for a way to stop everything after let's say 2 minutes of not being used.

 

[Reply #3 on:]

That's almost certainly a bug with your code, there's no reason for an atmega to require reprogramming after such a short period of time, and the only two ways I could think for something similar to happen require the reset pin to be either bounced or held and then for specific protocols to be on specific pins.  Forcing your users to reset the device constantly is a bandaid at best, perhaps if you posted your code we could help you find the actual bug that slipped through and is really causing it. 

My first instinct would be something that's written/read from the EEPROM, but that survives a normal reprogramming anyway, so the only effects that you're left with from a programming cycle are exactly the same as you'd get from just pressing the reset button.

[Reply #4 on:]

So the sketch won't run after a reset, but will run after re-uploading?  AFAIK that can only mean the flash is being corrupted, and normally only the bootloader can write to flash, although the bootloader can do crazy things under low power.  Are you running from batteries, and is the brown-out protection set?

[Reply #5 on:]

Thank you both for the replies.

I really doubt it's the code. I'll try a few tests with various power supplies and if I don't find the problem, I'll post the code.

@tim7: Yes, once the problem appears the sketch won't run after resets or after turning the unit off and on. I am using Atmega8-16PU chips with the single sided Arduino board. It does not even run the code and it does not seem to get past the bootloader. I am uploading the standard bootloader before I burn the sketch trough the serial port. Should I try uploading without the bootloader with a parallel programmer? 

Yes, the units run on batteries.

This happens only after the unit is left continuously ON for more than 10-12 hours or a few days. If I swap the Atmega with a fresh one or upload the sketch again, it works as it should. Now I remembered that I never tried the fresh chip with the old batteries. The users would change them thinking the batteries are the problem and send the units back with the new ones.

I will try to do 2 tests. One with a battery and one with a power supply that keeps the voltage constant throughout the test. 

I don't know what the brown-out protection is.   

[Reply #6 on:]

I forgot to mention that when I burn the sketch again, I burn the bootloader again, too.

[Reply #7 on:]

If the end user can't reflash the chip themselves why not just get rid of the bootloader all together?

If your board runs fine for days at a time plugged into mains power no problem then the brownout settings sounds like a good call to me.  I'm definitely going to have to reprogram my own project with that fuse :p

[Reply #8 on:]

The brown-out detector (BOD) engages the microcontroller reset whenever the power supply falls below a pre-set voltage level, stoping it from running when there is insufficient power for it to operate reliably.  If the BOD is not set, then there is potential for CPU instructions to become corrupted mid-execution, with unpredictable results.  The BOD is set by the "extended" fuse byte, and if you're using the Arduino IDE this value can be found in the hardware/arduino/boards.txt file.

For example, the UNO board runs at 5V and 16MHz.  By default the BOD is set to 2.7V, but in theory 3.8V is needed to operate reliably at 16MHz.  To be more conservative one would increase the BOD threshold to the next value up, which is 4.3V.

My own experience with the ATmega328 chips is that they run fine at 2.7V and 16MHz, but it may depend on what you're doing with them.  Are you using a standard Arduino board, or something specially designed?  Is there anything connected which draws a lot of power, and is there sufficient capacitance on the power supply to smooth out any glitches?

[Reply #9 on:]

It's a sort of ballistic chronograph for slowish projectiles, not bullets

Pumpkins?

I am looking for a way to stop everything after let's say 2 minutes of not being used

$7 and some of your time will solve the problem.  Pick the one that best matches the battery voltage...

http://www.pololu.com/catalog/product/750
http://www.pololu.com/catalog/product/751

[Reply #10 on:]

Thank you all for the replies! I'd like to try and solve this problem from the code and not by adding more hardware.

I've just finished a 24 hour test with a power supply that delivers 8.03 Volts. The unit is still working great. I will do one with a battery and see what happens.

Yes, I have an LCD display that draws quite a bit of power. I think the whole unit will use a 9V battery in about 10-12 hours.

I've changed the Atmega for the test from an Atmega8-16PU to an Atmega8A-PU. Couldn't find the 16PU one

I've read before about the fuses on the Atmega but never did anything with them and never really understood them. Is there a beginner tutorial that you can recommend. How do I enable the brown out detector for example.

I will post my findings from the power tests. I plan on doing tests with a chip with the bootloader on it, one without (sketch uploaded with the parallel programmer) and with the brown out setting enabled and disabled. It will probably take a week or more before I do all the tests. If the problem is the drained batterie's low voltage, I'll try to get my hands on a power supply with adjustable voltage and see at what voltage the problem appears.