Powering up Serial source triggers hang

[cefn]

I have been developing the prototype a bit further and have the following code, which hangs if I power the CO2 sensor on after the micro:bit.

If I power on the sensor first, and THEN start the micro:bit then it often (but not always) can run the code without a hang.

Note there is no usage of the serial in this at all, and the sensor doesn't send data all the time, only in response to a serial request so I don't expect a huge flood of data, (although I don't know if there's any kind of startup serial data sent).

The circuit is the micro:bit, the sensor attached as...

• GND: Common Ground
• 14: 3.3V UART TX
• 15: 3.3V UART RX

...and a tact switch attached as...

• Leg1: 3V
• Leg2: 16

In normal operation it scrolls 0 when unpushed and 1 when pushed. However, when the sensor is brought to life while the micro:bit is running, then the display goes permanently dark. It reliably hangs when the sensor is powered up after micro:bit reset. Sometimes a reset of the Microbit while the sensor is still powered on restores function, sometimes it hangs again.

The code below was compiled based on the microbit dal import on the MBed compiler from a few days ago, plus the single-line patch to remove serial free as mentioned by @jamesadevine

If this considered the same bug as previously, then happy to collapse them.

#include "MicroBit.h"

MicroBit uBit;

int main()
{
    uBit.init();
    uBit.serial.baud(9600);
    uBit.serial.redirect(MICROBIT_PIN_P14, MICROBIT_PIN_P15);

    while(1)
    {
        uBit.display.scroll(uBit.io.P16.getDigitalValue());                
    }

}

[finneyj]

@cefn - do you think this is related to serial at all? What if you take out the two line related to serial initialization?

uBit.serial.baud(9600);
uBit.serial.redirect(MICROBIT_PIN_P14, MICROBIT_PIN_P15);

Behaviour changing with power-on ordering can often be a symptom of a hardware issue. i.e. unstable power supply etc.?

[cefn]

Sorry not to have specifically noted this. I recall completing the sanity-check step you mention before posting. That was exactly what motivated me to post.

The sensor has now been shipped to the client, (along with instructions for a working reset sequence), so I don't have access to recreate the circuit and replicate those steps with certainty. To investigate further, it might be worth me waiting until I'm reunited with the sensor, (or its equivalent, the MH-Z14A which is being shipped). Then I can answer your question directly.

Even if the hang is dependent on the UART init, the serial invocation may still only have the effect of exposing the micro:bit to pre-existing power-supply problems, given the serial initialisation changes the internal wiring status of those pins.

Please note, however, that the sensor and microbit don't share a power circuit at all (the sensor runs from 5V though has a 3.3V output) so I was expecting that the micro:bit running from its own USB power supply should be robust enough to handle a sensor coming to life and transmitting on its UART lines via an entirely separate switched mains 5V power supply. I am happy to get your feedback if you think this is naive from a hardware point of view.

When I have time, I should take responsibility to replicate the same circuit and serial interaction with two microbits, to see if the same byte sequences with arbitrary power-up timing can replicate the hang. If it's only an interaction with this one sensor and power supply then this isn't something your team should be bothering with.

However, for this case, if you can't power up either the Microbit first OR the sensor first without reliably avoiding a hang, (as reported), then are you saying microbit stability might rely on them coming to life in direct synchrony (e.g. a switch which powers two separate-voltage circuits within microseconds of each other)? On the plus side, in this configuration once they have successfully connected, they stay connected without a hang.

[finneyj]

Thanks @cefn. A shame you don't have the hardware to hand so we can have a reproducible case.

I'm not saying that there isn't a bug in here - if there is we certainly want to know about it! It's more that, based on your symptoms, this feels like a hardware issue, so I was just trying to rule that out first...

Agree that the hardware configuration you describe should be ok... just trying to narrow this down.

Assume you had common ground lines between the two power supplies?

[cefn]

Assume you had common ground lines between the two power supplies?

Correct. The circuit was deliberately a demo given I experienced the same thing in the full-blown circuit and was trying to work back to the minimum to recreate. For that reason I should be able to demonstrate the same with two microbits if it's genuinely a UART timing/content issue.

[finneyj]

yes - please do... would be good to know.

[dpgeorge]

Note that there is a problem with the mbed UART driver that came up a while ago: on the MicroPython build, with the UART at 115200 baud, if you "paste" a lot of characters at once (like more than 15) to the serial prompt then you get mixed up characters printed back, but actually the characters that were received were received correctly. Furthermore, from then on the UART always responds twice for each character it receives. It was never resolved and is very easy to reproduce (just paste characters to the REPL).

[finneyj]

eeuughhh. Nasty... presume that was through USB UART? Could be a feature of the KL26 firmware. Would be interesting to see if it is indeed verifiable as mbed driver by using UART over external pins.

[dpgeorge]

presume that was through USB UART?

From what I can remember the bug is there even with the UART redirected to the external pins, so unlikely anything to do with the KL26.

[finneyj]

thanks. good to know.

[DavidWhaleIET]

Ah yes, I saw that ages ago when I was first experimenting with the early MicroPython REPL last year. I just assumed it was a MicroPython thing that was in hand, and didn't report it, sorry. Yes, it's a real jumble when that happens. I also saw some evidence of this when testing my proof of concept remote control python build, (which has now been completely re-engineered into microperi), so you might want to engage with Joe Glancy and Andrew Mulholland to see if they have seen this at all in their testing, as microperi (like my original mb_remote) uses the Python REPL under the bonnet. D

[finneyj]

Thanks @DavidWhaleIET. I'm maxed out for the next few weeks (busy time of year for Universities!), but we should indeed look into this. If there's a bug in the mbed nrf58122 port, we can work with Nordic to resolve it. It could easily be there - i've found one or two others in there before now.

[finneyj]

@cefn - did you ever get to the bottom of what was causing this issue?

[cefn]

Unfortunately, though I was expecting the device back imminently after studio presentation to continue testing, it became popular enough to still be on tour around the country somewhere (with the power-sequencing workarounds in place). ETA around 3 weeks to come back to us I think.

[pelikhan]

Our Microsoft team in London has devices for testing. Maybe they can help? Ping me at [email protected]:[email protected] .

From: Cefn Hoile [mailto:[email protected]]
Sent: Thursday, June 23, 2016 4:39 PM
To: lancaster-university/microbit-dal [email protected]
Subject: Re: [lancaster-university/microbit-dal] Powering up Serial source triggers hang (#152)

Unfortunately, though I was expecting the device back imminently after studio presentation to continue testing, it became popular enough to still be on tour around the country somewhere (with the power-sequencing workarounds in place). ETA around 3 weeks to come back to us I think.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com//issues/152#issuecomment-228217262, or mute the threadhttps://github.com/notifications/unsubscribe/AD-4KcsAfxTTLoocq6C2LQaGFwSJZvhtks5qOxkSgaJpZM4Iq6To.

[jamesadevine]

@cefn I think floating inputs / lack of common grounds are the cause of this issue.

I suspect they cause an ERROR on the UART bus and for some reason that is propagated to a hard fault handler, which I'm sure is not the behaviour we want.

This can be tested pretty simply by connecting up external TX/RX without a common ground, then calling redirect. A similar thing happens if you leave TX or RX disconnected.