AnalogIn test Failed on a new platform because the voltage cannot drop so quick

[soramame21]

I got a AnalogIn test failure.

Log analysis

1. Following log shows 1st call of AnalogInput_Test(), which located in ci-test-shield\TESTS\API\AnalogIn\AnalogIn.cpp, passed, then followed calls (case 2, ..., case 5) got failed.
2. All failures hit TEST_ASSERT_MESSAGE(ain.read() > prev_value,"Analog Input did not increment. Check that you have assigned valid pins in mbed_app.json file") at 1st loop in for(x = 0; x<5; x++) in AnalogInput_Test().
3. Which means that at beginning of loops, the AnalogIn value with outputs = 0, which cleared all dout_pin bits (= turned off the output voltage), is bigger than the AnalogIn value with outputs =1, which only set the least dout_pin bit.

A. The log with more printf, the failed point is marked by <<

[1500546174.03][CONN][RXD] >>> Running case #1: 'Analog Input on AIN_0'...
[1500546174.08][CONN][INF] found KV pair in stream: {{__testcase_start;Analog Input on AIN_0}}, queued...
[1500546174.09][CONN][RXD] outputs=0x1
[1500546174.11][CONN][RXD] prevValue=0.000000
[1500546174.13][CONN][RXD] ain=0.015640
[1500546174.13][CONN][RXD]
[1500546174.13][CONN][RXD] outputs=0x3
[1500546174.16][CONN][RXD] prevValue=0.027370
[1500546174.18][CONN][RXD] ain=0.043011
[1500546174.18][CONN][RXD]
[1500546174.18][CONN][RXD] outputs=0x7
[1500546174.21][CONN][RXD] prevValue=0.055718
[1500546174.23][CONN][RXD] ain=0.070381
[1500546174.23][CONN][RXD]
[1500546174.23][CONN][RXD] outputs=0xf
[1500546174.25][CONN][RXD] prevValue=0.083089
[1500546174.26][CONN][RXD] ain=0.097752
[1500546174.26][CONN][RXD]
[1500546174.28][CONN][RXD] outputs=0x1f
[1500546174.31][CONN][RXD] prevValue=0.111437
[1500546174.31][CONN][RXD] ain=0.125122
[1500546174.33][CONN][RXD]
[1500546174.36][CONN][INF] found KV pair in stream: {{__testcase_finish;Analog Input on AIN_0;1;0}}, queued...
[1500546174.43][CONN][RXD] >>> 'Analog Input on AIN_0': 1 passed, 0 failed
[1500546174.43][CONN][RXD]
[1500546174.48][CONN][RXD] >>> Running case #2: 'Analog Input on AIN_1'...
[1500546174.53][CONN][RXD] outputs=0x1
[1500546174.53][CONN][INF] found KV pair in stream: {{__testcase_start;Analog Input on AIN_1}}, queued...
[1500546174.55][CONN][RXD] prevValue=0.160313 << in 2nd call of AnalogInput_Test()
[1500546174.56][CONN][RXD] ain=0.074291
[1500546174.56][CONN][RXD]
[1500546174.68][CONN][RXD] :50::FAIL: Analog Input did not increment. Check that you have assigned valid pins in mbed_app.json file
[1500546174.69][CONN][RXD] outputs=0x3
[1500546174.71][CONN][RXD] prevValue=0.027370
[1500546174.73][CONN][RXD] ain=0.043011
[1500546174.73][CONN][RXD]
[1500546174.73][CONN][RXD] outputs=0x7
[1500546174.76][CONN][RXD] prevValue=0.055718
[1500546174.78][CONN][RXD] ain=0.070381
[1500546174.78][CONN][RXD]
[1500546174.78][CONN][RXD] outputs=0xf
[1500546174.81][CONN][RXD] prevValue=0.083089
[1500546174.83][CONN][RXD] ain=0.097752
[1500546174.83][CONN][RXD]
[1500546174.83][CONN][RXD] outputs=0x1f
[1500546174.86][CONN][RXD] prevValue=0.111437
[1500546174.86][CONN][RXD] ain=0.125122
[1500546174.86][CONN][RXD]
[1500546174.93][CONN][INF] found KV pair in stream: {{__testcase_finish;Analog Input on AIN_1;0;1}}, queued...
[1500546175.01][CONN][RXD] >>> 'Analog Input on AIN_1': 0 passed, 1 failed with reason 'Test Cases Failed'
[1500546175.01][CONN][RXD]
[1500546175.06][CONN][RXD] >>> Running case #3: 'Analog Input on AIN_2'...
[1500546175.11][CONN][INF] found KV pair in stream: {{__testcase_start;Analog Input on AIN_2}}, queued...
[1500546175.13][CONN][RXD] outputs=0x1
[1500546175.13][CONN][RXD] prevValue=0.155425 << in 3rd call of AnalogInput_Test()
[1500546175.15][CONN][RXD] ain=0.072336
[1500546175.15][CONN][RXD]
[1500546175.26][CONN][RXD] :50::FAIL: Analog Input did not increment. Check that you have assigned valid pins in mbed_app.json file
[1500546175.28][CONN][RXD] outputs=0x3
[1500546175.30][CONN][RXD] prevValue=0.027370
[1500546175.31][CONN][RXD] ain=0.042033
[1500546175.31][CONN][RXD]
[1500546175.33][CONN][RXD] outputs=0x7
[1500546175.35][CONN][RXD] prevValue=0.055718
[1500546175.36][CONN][RXD] ain=0.069404
[1500546175.36][CONN][RXD]
[1500546175.38][CONN][RXD] outputs=0xf
[1500546175.39][CONN][RXD] prevValue=0.083089
[1500546175.41][CONN][RXD] ain=0.097752
[1500546175.41][CONN][RXD]

Fax plan A & B

4. when the 1st call of following function is passed, the voltage is high. then 2nd call happened.
   dout_pin bits are cleared at line a, at this moment the voltage is still high cannot drop quickly.
5. Plan A
   A 100ms delay loop is added at line b. to wait for the voltage going down. If I remove the line b, and run to line c, at this moment x=0, then prev_value will be a big value > followed ain.read() to hit the TEST_ASSERT_MESSAGE().
   but I'm not sure how many targets will have this voltage dropping slow issue. it seems like that the most of targets don't need the 100ms wait to run AnalogIn test case. so I made another fix.
6. Plan B
   It's not necessary to add line b delay loop, but line d.
   Because the root cause is that the voltage output is not turned off at end of previous test, so I just add line d to stop voltage output at end of AnalogInput_Test().

B. ci-test-shield\TESTS\API\AnalogIn\AnalogIn.cpp, with fixed code

// Template to set one Analog pin as input and then cycle through the rest as outputs.
// As you turn more pins on the voltage on the ain pin will go up.
template <PinName ain_pin, PinName dout_pin1, PinName dout_pin2, PinName dout_pin3, PinName dout_pin4, PinName dout_pin5> 
void AnalogInput_Test()
{
    AnalogIn ain(ain_pin);
    BusInOut outputs(dout_pin1,dout_pin2,dout_pin3,dout_pin4,dout_pin5);
    outputs.output();
    int x = 0;
    int y= 0;
    outputs = 0;   //line a
    while(ain.read()>0.0f){    //line b, actually the loop only run once on xxxM066
        wait(0.1);    // plan A : the effective delay is required for xxxM066. 7/12 - ren
    }
    float prev_value = 0;
    for(x = 0; x<5; x++) {
        DEBUG_PRINTF("X=%d\n",x);
        prev_value = ain.read();    // line c, the 1st read value, when x=0, should be 0.0f !
        y = (y<<1) + 1;
        outputs = y;
        //wait(0.1);      // this delay is not effective, cannot fix the failures. 7/12 - ren
        DEBUG_PRINTF("outputs=0x%x\nprevValue=%f\nain=%f\n\n",y,prev_value,ain.read());
        printf("outputs=0x%x\nprevValue=%f\nain=%f\n\n",y,prev_value,ain.read());
        TEST_ASSERT_MESSAGE(ain.read() > prev_value,"Analog Input did not increment. Check that you have assigned valid pins in mbed_app.json file")
    }
    DEBUG_PRINTF("Finished the Test\n");
    outputs = 0;        //line d, plan B : 2nd way to fix, this is better. ren
    TEST_ASSERT(true);
}

[0xc0170]

I am bit confused with lines a-d above. Could you possible to provide each separately and the behaviour actual/expected?
Looking at it, seems like line d should fix what you are seeing but the start of the test sets the outputs to 0 also.

[soramame21]

sorry for unclear description. There's 2 ways to fix the issue.
1st way (I called plan A)
Just added a while loop at beginning withno line d. I could not observe the loop taking longer time than 100ms actually.

while(ain.read()>0.0f){    //line b, actually the loop only run once on xxxM066
    wait(0.1);    // plan A : the effective delay is required for xxxM066. 7/12 - ren
}

2nd way (I called plan B)
It's the alternative fix of above while loop. line d only is added instead of the while loop.

[BlackstoneEngineering]

@mray19027

[BlackstoneEngineering]

@soramame21 what platform are you testing this on? This is the first time we've seen this issue.

It may be worth adding a corner case test to catch this. Either way if the platform cannot meet the current testing infrastructure it needs to have a warning on its platform page about limitations on its AnalogIn speed.

[soramame21]

@BlackstoneEngineering This is a pre-release platform working with 5v not 3.3v. the ci-test-shield is modified specially, it's quite different from others. I think we may not need to make further investigation on it. I'd like to close this issue. What is your comment or suggestion?

[soramame21]

@BlackstoneEngineering I close it now. if it's necessary to go deeper, we can reopen it.