The Error 13313s seem to come when hid.tap() calls are made on a HID connection while also doing NRF.disconnect(), NRF.sleep(), NRF.wake() in various combinations. I'm not entirely sure yet. I think it might be a case of the service characteristics getting lost after an NRF.wake(), but redoing them fails too. I'm seeing these 13313 errors in the Espruino IDE when connected with Web Bluetooth, so there is a connection open with the computer, albeit UART.
The context: the script sets timeouts to make it execute NRF.disconnect(); ... NRF.sleep() after a set time (5 mins) of inactivity; each button press will clearTimeout() and start a new 5 minute timeout. Then, when the button is pressed, an NRF.wake() call is made if necessary, before hid.tap() is called subsequently on release.
When this behaviour works (it has sporadically worked in random hack versions along the way) it works really well - the Puck disconnects and shuts down when idle, and then wakes up and posts a keypress when it's activated with a click (forward) or a double-click (back)
And, if the on-screen keyboard is wanted, you can prematurely disconnect and sleep the Puck with a triple-click. That also acts as a manual "Off" when you remember to do so rather than idling it for five minutes.
A long click does a disconnect without a sleep, allowing Web Bluetooth to see the Puck for long enough to connect to it for maintenance.
Anyway, I wouldn't analyse that too much: part of the problem of getting you a neat little test case is the unpredictability, and the limitation of debugging while also having connects and disconnects, sleep and wake happen at the same time... I'm mainly working on cryptic LED flashes. I am still trying to isolate it though. My weekend's packed, unfortunately.
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.
The
Error 13313
s seem to come whenhid.tap()
calls are made on a HID connection while also doingNRF.disconnect()
,NRF.sleep()
,NRF.wake()
in various combinations. I'm not entirely sure yet. I think it might be a case of the service characteristics getting lost after anNRF.wake()
, but redoing them fails too. I'm seeing these 13313 errors in the Espruino IDE when connected with Web Bluetooth, so there is a connection open with the computer, albeit UART.BLE_ERROR_GATTS_SYS_ATTR_MISSING
composes to13313
. Pertinent? https://devzone.nordicsemi.com/question/6085/strange-error-code-13313-0x3401-returned-by-sd_ble_gatts_hvx/?answer=6106#post-id-6106The context: the script sets timeouts to make it execute
NRF.disconnect(); ... NRF.sleep()
after a set time (5 mins) of inactivity; each button press willclearTimeout()
and start a new 5 minute timeout. Then, when the button is pressed, anNRF.wake()
call is made if necessary, beforehid.tap()
is called subsequently on release.When this behaviour works (it has sporadically worked in random hack versions along the way) it works really well - the Puck disconnects and shuts down when idle, and then wakes up and posts a keypress when it's activated with a click (forward) or a double-click (back)
And, if the on-screen keyboard is wanted, you can prematurely disconnect and sleep the Puck with a triple-click. That also acts as a manual "Off" when you remember to do so rather than idling it for five minutes.
A long click does a disconnect without a sleep, allowing Web Bluetooth to see the Puck for long enough to connect to it for maintenance.
Anyway, I wouldn't analyse that too much: part of the problem of getting you a neat little test case is the unpredictability, and the limitation of debugging while also having connects and disconnects, sleep and wake happen at the same time... I'm mainly working on cryptic LED flashes. I am still trying to isolate it though. My weekend's packed, unfortunately.