Hardware » Awaria

[[Schematics]]

h1. Wiki

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 i2c is functional

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

* CANDis; measure RTC durability

* CANSwitch; check I2C-EEPROM-Config reliability

* Long time boot tests

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

* CANBus-In

* CANBus.Out

* Power in, 5V, -3V-

* Power out, 5V, 3V

* -USB PC to MCU-

* -USB PC to DUT-

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.