Clever Geek Handbook

Embedded Systems Hardware Test Automation

We continue the series of articles on testing automation of Embedded systems. This article will tell you how to quickly and relatively easily integrate the ability to control the power of the device under test from a test script, as well as get the ability to simulate pressing mechanical buttons on a command from a test script.



So what we have:



  1. Dozens of Embedded devices in which you need to test the new version of FirmWare (to be more precise, daily firmware assembly)
  2. Due to the nature of the FW boot procedure, it may be necessary to reset the power (the so-called firmware download mode in Power On Capture mode)
  3. I would like at some specific points in time during the execution of the test script to simulate clicking on the mechanical buttons located on the Embededed system debug board



Why might point 3 be needed? In my case, the task is as follows - in the event of a critical Exception of code execution, the system “gets up” to a half-dead state from which it will not exit until it is powered off (another reason for power management). But the most interesting thing is that if in this mode you press the mechanical button specially designed for this purpose, the so-called Exception log - debugging information on which it will be possible to try to understand in what place an exception occurred on the code.



It is precisely for this reason that for the effective automation of the test installation, it became necessary to be able to reset the power supply of the device and simulate pressing the mechanical buttons on the debug board thereby “saving” very important information on Exception from losing it soon. sooner or later, a test script realizing that there is no response from the device will try to reanimate it by resetting the power.



A small lyrical digression - sometimes you will run for weeks behind this Exception because it arises only sometimes when all the stars converge and a bunch of other conditions are not met. Therefore, each such debug log is very important and necessary.



Analysis of the circuit board debugging showed that the button simply closes the GPIO line pulled up to +3.3 V on GND. So if you "solder" to the button and use the relay to close the GPIO line to the ground, then that will be what you need.



Next, the question arose of choosing a device / module for control to which the following requirements were put forward:





By tradition, they stopped on the Etherent module of the Laurent-128 relay:







The module in all respects arranged us as a mess: you can manage 14 devices at once (one relay for power, the other at the press of a button) using URL commands (very convenient for script languages ​​in which test automation is written).



The connection and communication diagram of the debug board of the device under test and the control module is shown in the figure below:







“Soldering” to the contacts of a mechanical button on the example of one of the tested devices looks like this:







Hooray! The technical part is done. The only thing left is to add the code of the test procedures so that if necessary (download the firmware image after a power reset or record debugging at the touch of a button) give a command to turn on / off the desired relay.



The syntax of the control command URLs is simple and obvious. For example, in order to enable the relay under number 4, you need to use the following HTTP address: 



http://192.168.0.101/cmd.cgi?psw=Laurent&cmd=REL,4,1


And here is a simple function in Perl that is called from the main test procedure if you need to “pull” the relay: 



 #---------------------------------------------------------------# # FUNCTION:: click rele # PARAM1: Laurent IP adress # PARAM2: RELE ID # PARAM3: 0 / 1 - what to do with rele #---------------------------------------------------------------# sub func_click_pwr_rele { my ( $_IN_IP, $_IN_RELE, $_IN_VALUE ) = @_; my $url; $url = "http://".$_IN_IP."/cmd.cgi?cmd=REL,".$_IN_RELE.",".$_IN_VALUE; my $content = get $url; if( defined $content ) { } else { func_put_reslog( "ERROR! Can't manage RELE at adress $url", "BAD" ); } }


I note that the system works very reliably without crashes and freezes. Laurent-128 and the previously used Laurent-112 (for 12 relays) worked for a couple of years without failures and stops, taking into account daily work.



And here is an example of such an Exception that was identified during tests with an extraordinary daily firmware assembly. After it became clear to the test script that there was no answer from the device on the serial port (that is, it "died"), an attempt was made to press the emergency mechanical button to record debugging and this worked - the final test report generated by the test script itself was filled with useful information from the place of a possible system crash for further analysis by the development team:









More articles:


All Articles