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.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
I was going to say I've managed to isolate it down to a few lines of code, but ended up with this situation:
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 doneNRF.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.