mbed OS / Nordic nRF51-DK serial port functionality is inconsistent.

[nuket]

Trying to reconfigure the serial port in use by the Nordic nRF51-DK seems to be inconsistent:

If I use the Blinky example as follows, it will not start to output data on pins p12 and p13 of my nRF51-DK board. On mbed Classic, this seemed to work fine, albeit the various issues with non-connected hardware flow control, which seem to be endemic to the Nordic chips.

The method calls to anotherPort end up changing the baud rate of communications to the serial port connected to the /dev/ttyACM0 device, and printing to the mbed ACM device.

#include "mbed.h"

DigitalOut led1(LED1);

Serial anotherPort(p12, p13);

// main() runs in its own thread in the OS
// (note the calls to Thread::wait below for delays)
int main() {
    anotherPort.baud(115200);
    anotherPort.printf("Start.\n");

    while (true) {
        led1 = !led1;

        anotherPort.putc('*');

        Thread::wait(500);
    }
}

Another issue I've seen with this exact code is that the serial data indeed would be emitted via pins p12 and p13 of my nRF51-DK to a receiving device on /dev/ttyUSB0. Yes, that's right, same code, two completely different behaviors.

Also, more troublingly, the board could be induced to hang by playing with the DTR and RTS pins on /dev/ttyACM0. I could have two instances of CoolTerm open, and twiddling those pins in one window would cause the other window to stop seeing asterisks being transmitted.

I'm wondering if this is a static initialization order issue of some kind...

[0xc0170]

cc @pan-

[nuket]

Also noticed: with the anotherPort codes in place, LED1 will not start blinking until I connect to the /dev/ttyACM0 development serial port with CoolTerm. The whole system hangs until then.

And after I disconnect from the development serial port, the board will hang again.

[pan-]

@anangl We need your help on this one.

[nvlsianpu]

Unfortunately NRF5x_DK targets have serial port configured to use flow control - think a good idea is to providing configuration over mbed config system for flow control.(as was mentioned in this conversation #2482). I will try to resolve this issue.

[nuket]

Yes, this would be a very good thing to make configurable.

It is, in my mind at least, a pretty insane thing to have an infinite while() loop in the HAL code halt my program because of debug statements, and the current behavior definitely does not follow the path of least surprise.

[nvlsianpu]

#2535

[nuket]

Thanks for working on this!

[nuket]

Confirmed #2535 fixes this issue when hardware flow control overridden in mbed_app.json:

"target_overrides": {
    "NRF51_DK": {
        "target.uart_hwfc": 0
    }
}