Testing routine

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

Dear all,

Once the code is uploaded the design with all components should work. Ok, but sometimes things go bad :) therefore, I am wondering what can be done in terms of software and at tiny?

Is there a way to measure the voltage explicitly eg like BOD does, but on a power supply pin or some individual pin?

Is there a way to test the ISP to where the senzor is connected? So far I can test, if connection is established... but is there a standard way to do this?

Indeed, what is a usual and best way to approach to help and make a test with the tiny’s peripheral components?

Its a bit cumbersome to test each deasign manually. Is there a way to do that automatically with thw uC, such as at tiny?

Best.

Bravo!!!

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

mu234 wrote:
So far I can test, if connection is established... but is there a standard way to do this?
No (I/O varies)

What is standard are safety standards; implementations of standards will vary (specifications, designs)

mu234 wrote:
Is there a way to do that automatically with thw uC, such as at tiny?
Yes for CPU and memory; somewhat for I/O (designs vary)

Power supply tests vary as power supplies vary; test : coin cell nearly open circuit voltage, apply a current sink to coin cell, measure coin cell's voltage under nominal or specified load (under-volt means coin cell's capacity has been consumed, I/O to/from operator to replace the coin cell)

 


BIT : Built-In-Test

AN2632 : Guide to IEC 60730 Class B Compliance with tinyAVR® 1-series

via ATTINY3217 - 8-bit Microcontrollers

 

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

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

What sorts of tests are you thinking about, and in what sort of environment?

 

While developing software I like to have some kind of message that a uC is reset.

It could blink a led a few times, sound a buzzer, or send some data to a uart after each reset.

This gives positive feedback the progam is starting after a program cycle, but also gives feedback about spurious resets, which may go un noticed otherwise.

 

Production equipment is often tested on a "bed of nails", often even with firmware to easily excersize all outputs / inputs.

Software and hardware for this is always custom to the project, thoug sometimes sort of standarised libraries can be used, but often the goal is to keep the test firmware simple and small.

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com

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

Thanks, the coin cell sounds useful, can you elaborate a bit mote on it? An example?

Best.

Bravo!!!

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

Thanks, indeed bad of nails is already on my plate, bit is there something else that can be done along eg with the uC and standard libraries? Example?

Best.

Bravo!!!

Last Edited: Sat. Apr 13, 2019 - 06:57 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Paulvdh wrote:

What sorts of tests are you thinking about, and in what sort of environment?

The design along with componens is ready, solded, several pieces.

Now I want to test, if it works. It is powered and it has an output,
There are two ic on it. Senzor and uC. Senzor receives and gives r
to tiny via isp, while tiny makes decisions in environment, delivered to output!

The main idea is to test this ?

Sounds simple, but it is not.

Best.

Bravo!!!

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

Won't elaborate as there's an article that describes the method :

Hardware and Firmware Issues in Using Ultra-Low Power MCUs, by Jack Ganssle

8 - Most Brown-Out Reset Circuits Don't Work

...

(last two paragraphs)

 

Why coin cell?  maybe not (my intention was a common and simple off-the-shelf power supply)

http://www.ganssle.com/reports/ultra-low-power-design.html#cr2032behavior

 

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

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

mu234 wrote:
Thanks, indeed bad of nails is already on my plate, ...
bed of nails may be expensive for low-rate PCBA production; a PCBA manufacturer may prefer a PCBA-specific test instead of the generalized bed of nails test (that has custom programming)

AVR Xplained boards hardware documentation will have a thumb nail picture of the PCBA tester (pogo pins, operator inserts PCBA, press, test, pass or fail, release, remove PCBA, bin PCBA, repeat)

A PCBA tester may be operated by the ones in logistics (stock in for storage, stock out to customers and operators) though the ones in logistics may prefer to operate as operators do.

Operators likely won't have a PCBA tester; therefore, BIT software in AVR's flash.

 

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

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

Need a lot more info.

 

Sometimes built-in testing of the mission critical sub-systems is designed in as part of the original design.

 

Some "sensors" have multiple R/W registers, and often one register is a device ID or version number.

If you can read the senor's built-in ID then you know that the sensor is connected to the micro.

If you use another I/O pin to turn on a resistor heater near a temp sensor you can test that the temp reading increased when you applied the test signal to warm it up.

If you turn on a small pager / smart phone vibrator motor you can test that an accelerometer chip is working.

If you inject a signal into an external ADC analog front end you can verify the AFE is working.

In the old days, when indicator lights used filamented bulbs instead of LEDs, one could put a small current sense resister in the ground leg and read its voltage with an ADC to confirm that the bulb wasn't burned out.

Servos and stepper motor motion systems can have start up range of motion tests with limit switches for verify their operation.

 

The list goes on and on, but built-in self testing is best implemented as an original design requirement, not as an add on after thought.

 

JC  

 

Edit: Typo

 

 

 

Last Edited: Sat. Apr 13, 2019 - 10:17 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I build in the "mission critical" testing into the program, itself.

 

For example: I have 3 bicolor LEDs that are driven between two GPIO pins, each. So, on boot-up, I go through a test sequentially lighting red on each one, then green on each one. That serves both manufacturing and the user. User knows that it is "booting up". Manufacturing knows that all 3 LEDs are properly connected (risk: an LED might be installed backwards, which would give erroneous status indications to the user).

 

For example: I have a sensor on an SPI bus. It configures the bus, and attempts to read the "Who Am I?" register in the device. If it fails, an LED flashes red, if successful, same LED flashes green. Does this on every boot after the initial LED test. This tells manufacturing that the sensor is properly connected. It provides user confidence on each bootup.

 

The added code for these tests is pretty minimal, though the LED test has to rely on delay functions because no timer is configured at that point. 

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

mu234 wrote:
Is there a way to measure the voltage explicitly eg like BOD does, but on a power supply pin or some individual pin?

Vcc voltage can be calculated from using Vcc as the reference of the internal ADC, and then measuring the voltage of the internal reference.

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com

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

For many linear and switching regulators, their output is far more accurate than the internal reference. If you have a half-way good Vcc source, use it instead of the reference. Forget all that business of calibrating the reference.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

There is always a huge trade of between levels of quality control (testing) and cost of production.  The Chinese knows it very well and offers you the same product by $0.10 or $2.00, depending on how much reliability and quality verification and tests you want.  It always depend on the price you want to pay as manufacturer, and the price the market will want to pay as final product.

 

During my IBM time, there was a 4341 mainframe, it used a fantastic way to ensure everything was working in order, it was a fantastically huge parallel to serial ring, thousands of parallel to serial devices collected information from all over the places, all registers, processors, voltages, buses, every single thing was serialized in that huge serial ring data flow.  As far as I remember, that thing worked alone and in a timely manner, and serialize such information into a service processor that verify, decode and gives the green or red light for the mainframe to keep going.  If a single bit was off, the service processor would trigger a service mode that would exercise such area of the mainframe more deeply, if a problem was found, it will create a report and if the problem is critical it will halt the processor and will require a engineer/technician present for further diagnostics and parts replacement.

 

Can you imagine how much cost that kind of solution?  Of course, for IBM image and fast problem identification and repair, it would be a must, totally required, but not cheap.  In some way that would be more complex than the mainframe itself, and worst, that circuits are not failure free, they also can fail and create ghosts problems, could stop a very healthy and working mainframe for nothing, requiring a technician to replace an electronic card from the "doctors diagnosing brain", pure hallucination.

 

The dept of the tests in your circuit board is directly proportional to how much would you want to invest in software, additional hardware or production/quality control cost.

 

Some tests can be done uniquely by software, and it doesn't cost much, as you stated, test the connectivity with I/Os for example, testing SRAM, verifying the Flash contents, even checking voltage (measuring a Vdrop from a 1N4148 diode connected to VCC via a resistor, using the ADC using VCC as Vref).  Adding some cheap hardware around the AVR can allows you to loop back all I/O port pins (74HCT125 for example - with the gate being triggered for few milliseconds by a RC right after power-on), or even using some automated feedback system to an optical sensor to a testing computer, or a human providing testings by hand.

 

Somethings need to be really put in a balance, what you want, how much will you accept to pay for that.

 

When I buy small electronic boards cheap from China, I always buy two or three at once, just in case.  That is the price of increasing the chance to have at least one working.

  

Wagner Lipnharski
Orlando Florida USA