Hardware » Awaria

[[Schematics]]

h1. Wiki

(Polnisch fuer Ausfall, Stoerung)

There are some issues that can only be tested via power resets.

* SPI has an issue that it needs retries

* Looks like configuration I2C EEPROM gets reset to defaults

* RTC-offline-test (Wie lange haelt die RTC Batterie)

The device has an CANBus in and an CANBus out. The testsoftware is on the DUT. The DUT sends the command to toggle power line to Awaria via CAN.

The switch-off time has to be an parameter. The RTC-Tests will be complex, the Awaria software shall be simple and generic.

An data multiplexer can be used along with a mosfet for power line.

Data lines for CAN and UART have to be cut. 

In order to cut UART, an Debug-Adapter chaining would be needed. Or Uart is available via Host-USB.

Optionally controll it via USB from PC, not MCU. Optically isolated GPIOs.

h1. Problem

Circuit does not help at all when power is injected into device via Pullup of RS232. Lines can be disabled too. But whole

debug connector can cause issues: No debug connection at all.

FPC with UART only? All signals disconnectable?

A problem is the debug adapter. Switching the signals from one MCU to another is not nice. 

Flashing the MCU that controlls the lines may result in dead board. Fixed lines are better; always able to flash a device.

-Usually a reset is enough. The total off test is quite special. But there is no output available.-

The periphery tests need a complete disconnect, even when for some problems a reset was enough.

Uart of Awira? optional when main tests are running on PC.

DUT is connected to Awira via debug connector and canbus or power line.

Awira is connected to CAN bus.

PC is connected via debug board to Awira, signal routed to DUT.

Flip-Flop for debug routing would be nice. A big button to route the debug port is nice.

SN74LVC1G80DCKR

2xUart

2xSWD

2xBoot/Reset

VDD Target

-Jumperresistor to connect the uart of the DUT to awaria.-

h1. Usecases

* Devices have their own test-software and ask awaria to perform an power-cycle for them. Result is stored in option Bytes.

** Because the software is running on DUT, debug can stay routed to DUT.

* PC performs test. DUT has to send Log-Events when errors show up and when device is up and running. DUT firmware can be the productive firmware.

** Tester-Firmware on PC is quite generic

** CAN may not be available yet (CANDis). That was one intention of repeated log code

** CANDis may be configured to use USB. No UART output here. USB does also not help then.

* Long time tests. Device can be in a permanent reboot loop with alternating writing/reading EEPROM. Awaria can persist status and result. Cordyceps can readout values at any time.

h2. Usecases with products

* I2C has an issue that some times the board has to wait at bootup quite long time till i2c eeprom is functional.

** How much time can it take till i2c is functional

** Is fix working 100%; device will boot 100 times

* CANDis looses touch calibration; SPI has an issue that some times the board has to wait at bootup quite long time till spi flash is functional.

** How much time can it take till spi is functional

** Is fix working 100%; device will boot 100 times

* CANDis; measure RTC durability

** Can be done via Awaria in case the test has to run over months

* CANSwitch; check I2C-EEPROM-Config reliability

* Long time boot tests

* Miniminutnik

** redirected Uart would make sense here

h2. Problems:

* RTC: Cant check if there was an I2C problem or RTC was actually not valid. CI2cSlace-Class needs better status handling besides "isPresent". DeviceError or ContentError

* Waste biwak with TDT-Specific values? Use own error code range. LogEvents support custom data types.

h1. Parts

* MCU: The smallest thing

* Multiplexer: "Link":https://www.tme.eu/de/katalog/analoge-multiplexer-und-schalter_100222/?params=383:1443902,1474454_anzahl-kanale:4,16&activeView=parameter&onlyInStock=1&productListOrderBy=1000015

** MC14551BDG bis zu 1K RON: 1050

** TS5A23166DCUR cool, 2 channels, up to 100mA, 1,8-6,5V

** Habe:

*** DG408LEDQ-T1-GE3; .#273;  1:8

*** DG409LEDQ-T1-GE3; .#321;  2x 1:4

*** ADG736; .#315; 2x1:2

*** *RS2102XN ADG836YRMZ* Das ist er; 2x

** MAX4760; 8 Channels; Paarweise schalten

** TMUX1574 4xSPDT; 1 Schalter

** PI5C3257QE; 4xSPDT; 1 Schalter; 0.229€

* Big EEPROM, device can store test info from DUT. Maybe a second EEPROM just for costom data persisting. Can hold data in RAM.

Spannungs/Strom zu umstaendlich.

"Cables":https://www.tme.eu/de/katalog/ffc-fpc-bander_113269/?params=673:1451575;425:1478584;1184:1479746&activeView=parameter&queryPhrase=fpc&onlyInStock=1&productListOrderBy=1000015

h1. RTC-Tests

Can have a region in SPI-Flash.

If the Settings are not ok, just have an terminal.

The test can only be started from terminal.

rebootTest <startTime>

Start. 

* Cut 2 Seconds. Time OK?

* Cut 4 Seconds. Time OK?

* Cut 8 Seconds. Time OK?

When it fails, "destroy" test-config in spi flash

h1. Off-Desk tests 

* Awaria can toggle an CANDis till RTC is not valid any more.

* The test could run for month

* An eeprom is enough to store the result. The device can be connected to PC and data can be read via UART or CAN.

* Only CAN may be connected when debug is not accessible on device. Target Node-ID has to be configured. This can be done via CAN.

* Progress LEDs needed

* This is the 99,9% solution.

* Broken EEPROM-Config can not be detected because ID does not match any more; result is timeout. But reboot can be stoped, problem can be seen.

*

h1. Connectors

* CANBus-In

* CANBus.Out

* -Power in, 5V, 3V-

* Power out, 5V, 3V

* -USB PC to MCU-

* -USB PC to DUT-

* Debug in

* Debug out

Debug, CAN, power only?

CAN-Geraete koennten auch standalone laufen, Testsoftware auf PC.

2x Uart

2x SWD

1x Reset

1x Boot0

2x CAN

(DEBUG: VDD_5VIN, GND, VDD_TGT, SWO)

USB schalten is overkill, andere Platine.

* Battery lifetime checks.

* How long does minutnik-eink run with one charge?

** It has to send pings via Uart.

** Printing uptime periodically would do the job. -> Avoid power injection?

h1. Further examples

* Toggle miniminutnik till eeprom error. Instead of an battery, the 3V connector has to be feeded.

Strange setup; PC reads UART output of DUT and controls Awaria via CAN.

h1. Usecases

* Reboot until RTC is broken

** How to detect problems?

*** Device schickt selber commandos ab. Via CAN.

** Sobald geraet bootet funtkioniert Seriel auch wieder

Am einfachsten:

SWD ist garnicht durchgeroutet

Nur UART RX/TX gehen auf eigenen debug anschluss.

Ist device off, hat man eine COmmandline von Awaria.

Es koennen Programme abgefahren werden wie "peridoc 60 3".

Taster On/Off bricht Programm auch ab.

Auf dem Host sieht man abwechselnd Statistic und Target Output.

Awaria kann auch auf CAN Nachricht warten (I2C problem).

SWD doch durchrouten, dann ist flaschen kein Problem.