• I was going to say I've managed to isolate it down to a few lines of code, but ended up with this situation:

     _____                 _
    |   __|___ ___ ___ _ _|_|___ ___
    |   __|_ -| . |  _| | | |   | . |
    |_____|___|  _|_| |___|_|_|_|___|
              |_| http://espruino.com
     1v92 Copyright 2016 G.Williams
    pinMode(D29, "input_pulldown", true);
    NRF ERROR 0x8 at ?:0

    Hmm. I think there's something rather wrong. I've DFU'ed it back to 1v92, and tried various resets and flash resets. This is since I started doing NRF.setLowPowerConnection(true), although I've since done NRF.setLowPowerConnection(false) a few million times.

    UPDATE (#3): I've managed to get it (and the other Puck I soft-bricked) back using the five-green-flashes method, E.setBootCode(), although that didn't seem to help originally.

    This is all on 1v92 stock on one puck and 1v92.3045 (a fresh build) on the other.

    I think the NRF ERROR 0x8 is happening when it keeps reconnecting and then advertising changes while the connection is active, or something like that. I'm not sure if that makes sense.

    I've had big problems with setLowPowerConnection, as it messes with the timing, giving me runs of repeated taps.

    From my limited understanding of BLE, I can see that the idea of getting the client (the iPad) to stop connecting to the Puck is problematic. The only way I can see this working is if I can shut down BLE, or HID advertisement, and then restart it when a button is pressed to wake it up. setLowPowerConnection alone might save power, but it won't handle the disconnection I need for keyboard access.

    I'm still rather unclear on what can and can't be done while connections are open, and so forth. Some commands will queue for the next reset, but things like NRF.setAdvertising, NRF.sleep, NRF.wake might not have the right guards in there, and I think they may be causing the crashes and reboots.

    I'm still trying to isolate some code to demonstrate it.


Avatar for tom.gidden @tom.gidden started