Ble113 Scan "event unknown (unhandled)" after deep sleep

When I send my imp to deep sleep using “deepsleepfor()” command, after wakingup the scan events comes as “LOG: event unknown (unhandled)” instead of “LOG: event gap_scan_response”

2018-05-07 22:37:38 +05:30 [Device] LOG: call gap_discover
2018-05-07 22:37:38 +05:30 [Device] SEND: 00 01 06 02 01
2018-05-07 22:37:38 +05:30 [Device] RECV: 80 1a 80 0c 00 00 01 00 03 00 02 00 7a [z] 00 03 00 01 06 00 02 06 07 00 00 00 02 06 02 00 00
2018-05-07 22:37:38 +05:30 [Device] LOG: event unknown (unhandled)

The Log should have been like this

2018-05-07 22:15:23 +05:30 [Device] RECV: 80 1a 06 00 cd 02 11 22 ["] 33 [3] 44 [D] 55 [U] 77 [w] 01 ff 0f 02 01 06 06 08 81 81 81 81 81 81 00 00 00 00
2018-05-07 22:15:23 +05:30 [Device] LOG: event gap_scan_response

Does the data look good? The header seems valid, but I don’t know anything about the BLE113…

Hi hugo thanks for prompt reply
The UART buffer reads

2018-05-08 08:01:18 +05:30 [Device] binary: 80 07 07 00 99 f4 04 00 00 01 31 00 02 06 07 00 00 00 02 06 02 00 00
2018-05-08 08:01:18 +05:30 [Device] RECV: 80 07 07 00 99 f4 04 00 00 01 31 [1]

Will this help you to help me?

I am using the squirrel port of BGLib for ble112

I’m afraid I really can’t help, I’ve not used the BLE library ever.

Have you tried reinitializing the BLE after waking?

Hi hugo,
I found a solution.
imp.wakeup(10, function() {

imp.deepsleepfor(60);
});
Instead of calling imp.deepsleepfor(60); in onidle() I am calling it in imp.wakeup()
It worked fine, in this also if I make time 10->0.0 again same problem starts. and for other values less than 10 it some times recognises the event some times it dont. also I dry run the code I found the uart.read() is not reading correct headers (I think).
Did this gave you any clue what might be the possible problem?

“reinitializing the BLE after waking” I did not get, It will be always reinitialized after waking from deep sleep as code execution starts from the begining again, am I correct so I suppose waking from deepsleep is equivalent to fresh starting the imp?

I think there are many callbacks in the queue so befor all the call Backs fire imp again goes to deep sleep.(am I correct?)

10 secs is also not reliable it sometimes don’t work, again when the device is restarted it works.

The data I need is in the read buffer data but is preceded with other data also, I think the buffer is getting full and after reading the buffer parser is not able to parse it properly.

These informations may help to give some clue what might be the problem.

Leaving time before sleeping will not affect how the imp behaves on the next powerup. When the imp wakes, it is essentially a fresh boot of squirrel - all RAM contents have been lost, so there is no context at all.

My guess is that the BLE chip is not being powered down when the imp sleeps, and so has been continuing to send scan results to the imp. When the imp wakes and configures its UART, there are random bytes from the middle of packets being received which is confusing the code.

Hence you need to ensure the BLE chip is reinitialized, buffers emptied, etc before trying to start fresh.

I’m afraid debugging this code is not something we can help you with. If you were using the built-in BLE of imp004m then we could help you.

Hi hugo thanks for helping

I am flushing the buffer and disabling The UART also and then lowering the waKeup pin of BLE again I check it for its state then call imp.deepsleepfor(20); The BLE is reinitialized at the begining of the code. Where am I doing wrong? i am not getting

imp.wakeup(1.0, function() {
hardware.uartUVGD.flush();
hardware.uartUVGD.disable();
wakeupPin.write(0);
imp.wakeup(6.0,function(){
if(wakeupPin.read()==0){
imp.deepsleepfor(20);
}
})

});

As I said, I can’t help debug an application whose problem is with another device that we don’t have and don’t support…

Flushing a UART before sleeping is pointless; sleeping, as noted, loses all ram content (and IO configuration). You need to ensure you’re in sync with the BLE chip when you wake up. ie, stop changing how you go to sleep, and start looking at how to get back in sync when you start up.

Note also that ALL GPIOs are tristated when the imp is in sleep. Seems like there should be a pull-down resistor on your wakeupPin to ensure it stays low when the imp is sleeping, otherwise the BLE chip may wake the second the imp sleeps.