[ESP8266] Adds support for controlling HW reset of the modem from the…

[VeijoPesonen]

… driver

While connecting will run HW reset for the modem if reset wire is attached to a know pin.

Description

Brings possibility to use a known HW pin to attach the ESP8266 HW reset wire and to control it from the driver. Current implementation forces HW reset on each connect-call.

Pull request type

[ ] Fix
[ ] Refactor
[ ] Target update
[X] Functionality change
[ ] Docs update
[ ] Test update
[ ] Breaking change

[VeijoPesonen]

@kjbracey-arm, @SeppoTakalo, @marcuschangarm,  @karsev please review.

[0xc0170]

@VeijoPesonen Please review travis failures (related)

[VeijoPesonen]

@dlfryar, @marcuschangarm please try this PR when you have time.

[VeijoPesonen]

@VeijoPesonen Please review travis failures (related)

@0xc0170 Seems to be some kind of an build environment issue:

W:: command not found
The command "W: Failed to fetch https://packagecloud.io/computology/apt-backport/ubuntu/dists/trusty/InRelease Connection timed out after 10000 milliseconds 
W: Failed to fetch https://download.docker.com/linux/ubuntu/dists/trusty/InRelease Connection timed out after 10000 milliseconds 
W: Failed to fetch https://packagecloud.io/github/git-lfs/ubuntu/dists/trusty/InRelease Connection timed out after 10000 milliseconds 
W: Failed to fetch https://packagecloud.io/rabbitmq/rabbitmq-server/ubuntu/dists/trusty/InRelease Connection timed out after 10000 milliseconds" failed. Retrying, 2 of 3.

[VeijoPesonen]

@michalpasztamobica please review

[michalpasztamobica]

Looks good, just a minor optional suggestion if the task is not urgent.

[dlfryar-zz]

Adding @c1728p9

@VeijoPesonen I didn't get a chance to test this today. A quick look at the code seems like this is a big hammer approach to getting the module operational. Unless I misinterpreted the change or perhaps there's a change elsewhere, this does not handle a simple disconnect from the AP or the case where a watchdog timer reset the ESP.

My assumptions are if the ESP is doing I/O and the stack gets an OOB message from the ESP then checks the IP which returns 0.0.0.0 the driver/stack should do an initialize() again with the AP parameters. If that does not succeed then I'd expect the big hammer approach with the reset signal. An OOB status of busy from the ESP is another case where reset would not be unobtrusive action.

[VeijoPesonen]

Adding @c1728p9

@VeijoPesonen I didn't get a chance to test this today. A quick look at the code seems like this is a big hammer approach to getting the module operational. Unless I misinterpreted the change or perhaps there's a change elsewhere, this does not handle a simple disconnect from the AP or the case where a watchdog timer reset the ESP.

Already handled by PR's ARMmbed/esp8266-driver#103 and #8853

[VeijoPesonen]

My assumptions are if the ESP is doing I/O and the stack gets an OOB message from the ESP then checks the IP which returns 0.0.0.0 the driver/stack should do an initialize() again with the AP parameters. If that does not succeed then I'd expect the big hammer approach with the reset signal. An OOB status of busy from the ESP is another case where reset would not be unobtrusive action.

Would be worth of another PR, I would like to leave this one intact.

[VeijoPesonen]

Powering down the modem on disconnect and in destructor added. Please re-review.

[cmonr]

@VeijoPesonen There have been an uptick on those Failed to fetch https://packagecloud.io/... errors.

Travis CI is aware, and the most that we can do right now is restart the job. For now, I've restarted the two erroneous Travis CI jobs.

[VeijoPesonen]

Fixed a namespace collision, please re-review.

Fixed

[adbridge]

@kjbracey-arm @karsev are you guys happy with this now ?

[cmonr]

CI started

[mbed-ci]

Test run: FAILED

Summary: 1 of 11 test jobs failed
Build number : 1
Build artifacts

Failed test jobs:

• jenkins-ci/mbed-os-ci_greentea-test

[cmonr]

Restarting jenkins-ci/greentea-test.

Lone failure appears to be QSPI frequency setting test (test may need a refactor).

[cmonr]

Damn it. Figures that bringing in a 5.11.1 PR that was ready would cause an RC3 PR to need a rebase...

@VeijoPesonen Rebase to resolve the conflict when you can.

[cmonr]

CI job stopped: jenkins-ci/greentea-test

[VeijoPesonen]

@cmonr rebased

[0xc0170]

CI restarted (also one travis job)

[mbed-ci]

Test run: FAILED

Summary: 1 of 11 test jobs failed
Build number : 2
Build artifacts

Failed test jobs:

• jenkins-ci/mbed-os-ci_exporter

[0xc0170]

Exporter restarted