consequences of forget to set BOD

Go To Last Post
10 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1


I just gained some experience, I would like to share here.

 

After I finished the design and test tens of PCB samples of new product (RDM-DMX LED pixel bar luminaire) based on ATmega328P,

I prepared production file and embark to produce 300 samples (6 different models) of final luminaires.

Every thing seemed normal so far since all products successfully passed the individual tests and activation processes.

Then when I put all luminaires together and made a whole system test, the hidden calamity unveiled ! 

 

I forgot to set BOD fuse bits in production file !! :/

100 of them were disassembled and reprogrammed again, I happily did it! (5 days rework)

but my real punishment is to rework the remaining 200 pcs of luminairs which are filled with insulation resin ...

There is no way to disassmble them and reach the ISP pins which is burried under insulation resin.

firstly the metal enclosure must be CNC milled , then the insulation resin should be digged.

long days of rework are waiting for me !

 

 

Majid

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you for this lesson learned.

Condolences for your PITA.

m.majid wrote:
I forgot to set BOD fuse bits in production file !! :/
fyi, the process for programming by MicrochipDIRECT requires fuses and is another step in fuse verification (all fuse data is displayed)

Samples from MicrochipDIRECT programming can be for the product's qualification.

MicrochipDIRECT may be a fit for low-rate production (price, cost, risk)

mega328P is beta in MPLAB X v5.25 other than the AVR CPU simulator; MicrochipDIRECT programming has a path for AVR.

 

Programming Cost Lookup | Welcome to Microchip Technology | Microchip Technology Inc.

http://ww1.microchip.com/downloads/en/DeviceDoc/Programming-Center-Technical-FAQs-2018.docx

[page 7]

6. The generated hex file may have missing Configuration Settings information

Configuration settings are crucial to ensure a part operates correctly. If configuration settings information is missing from the hex file, it will result in checksum mismatch.

...

via

https://www.microchipdirect.com/faq-main?catid=1c99a89d-722f-69fd-9699-ff0000260584 (MicrochipDIRECT, FAQ, Programming)

[3/4 page]

I’m experiencing technical difficulties with my checksum value and hex file. Do you have a more technical FAQ sheet to help?

Yes, click here.

MPLAB IPE | View Menu - Developer Help

[1/4 page]

If the Config Memory is enabled, the configuration settings can be edited. Select Config Memory from the drop-down list in Memory View.

...

Programming Center - Getting Started | Microchip Technology Inc.

microchipDIRECT How To Tutorials - Programming Center Walkthrough - YouTube (2m19s)

[AVR at 40s and 1m46s]

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Never cover your programming pins in resin (just in case).

 

You don'r have to set the bod...what is the worst case possibility, in your case?

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:
Condolences for your PITA.
Thanks!
.
avrcandies wrote:
You don'r have to set the bod...what is the worst case possibility, in your case?
There are two issues:
1) EEPROM data corruption
Occures after several power off and on again the power supply
approx 2% of devices, EEPROM data stored @0x0010 address reset to 0xff

2) the device should count the POWER CYCLES as requirements (1 count per 1 power on)
With BOD it works fine, 1 count for 1 power on
Without BOD it counts several counts per 1 power on

Majid

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ow. Hard lessons.

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

metal enclosure must be CNC milled

And that, of course, could easily cause its own problems with small metal chips shorting out parts / PCB traces, etc.

 

Thanks for the post.

It is a good reminder!

 

JC 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Without BOD it counts several counts per 1 power on

That's a bit ridiculous ...How long do you delay before counting?...hopefully a second or so.  BOD should barely have an effect (assuming a decent supply).  

EE corruption could occur---but should be very rare, since you will only try to do EEsomething after the power is somewhat stable, which captures 99.9% of the time 

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:
That's a bit ridiculous ...How long do you delay before counting?...hopefully a second or so.  BOD should barely have an effect (assuming a decent supply).  
Indeed there is a 1 second delay at the beginning of my code.
I repeated the test hundreds of times, I can say definitely the BOD solves the undesired count issue.

Majid

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 I can say definitely the BOD solves the undesired count issue.

Why do you think so? Does the power flicker a lot once the program is up & running & past your delay? 

Apparently, without BOD the power going off must be allowing random sections of your code (or just random opcodes) to run & start a write to the EEPROM.

You might try using a different EEPROM address...I seem to remember some post about the first location being much more easily corrupted.    

 

Here is some old debate on the topic

https://www.avrfreaks.net/forum/eeprom-strategies?skey=%22first%20eeprom%22

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Sat. Sep 14, 2019 - 08:16 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:
Why do you think so? Does the power flicker a lot once the program is up & running & past your delay?

OK, you were right

I traced the "several count" issue, sometimes the EEPROM value becomes 0xff, so I mistakenly interpreted as several count, in fact it is EEPROM value corruption too.

 

avrcandies wrote:
You might try using a different EEPROM address...I seem to remember some post about the first location being much more easily corrupted.

I am aware of that , I always avoid first 16 bytes of EEPROM address from 0x0000 to 0x000f 

it is because of bad reset, I have read here : https://www.microchip.com/webdoc/AVRLibcReferenceManual/FAQ_1faq_eeprom_corruption.html

 

Anyway the BOD is the cure.

 

My manager suggests to place a hole in the luminaire case for future. so the program could be updated if required.

I myself am thinking about boot loader, so the program could be updated through RDM-DMX data cable of luminaire.

however I am not sure if FUSE bits also could be programmed by program code or not.

 

 

 

Majid