I have a custom embedded device which uses a Broadcom BCM 20736 BLE module containing an MCU which is programmed with custom firmware, using the WICED Smart IDE. The device acts as BLE server. Connected to the BLE module is another MCU, the main MCU of the whole device - which has firmware that needs updates.
On the other end there is an iPhone 6 with an app as BLE client.
We need to use BLE somewhat atypical, in that the main data direction is from client to server - for some 100 KB of data (firmware update of main MCU). There are occasional reply packets in server->client direction.
The app uses the Xamarin cross-platform framework, and it's cross-platform BLE abstraction Robotics library. While that one is in beta phase and not supported, what I could see so far is that the errors come directly from the lower levels, i.e. the iPhone native stuff, which I presume does not have such gross bugs by now, so I assume it's my embedded device that's faulty. Or perhaps, the beta Monkey.Robotics library uses the underlying iOS API wrongly? The Robotics interface is so slim that I guess it's hard to make mistakes in using - discover a device and its services and characteristics, and subscribe to events...
The update is supposed to be done via this setup:
Client to server, all with "write no response" property & "write cmd" permission:
- 1 control characteristic, 5 bytes payload
- 4 data characteristics, each 20 bytes payload
Server to Client, all with "notify" property and "readable" permission:
- 1 control, 5 bytes
- 4 data, each 20 bytes
The BLE server is programmed such that it sends a certain notification on the readable 5-byte characteristic after a certain command on the small writable one was written to the writable small one, or after all 4 big writable characteristics have been written to by the client, the latter being a sort of software "ACK", so the client knows it can send another 4 x 20 byte chunks.
For a test, we did this with only one control characteristic and one data characteristic configured like above, and got decent speeds out of it, and no strange errors.
Now with the full configuration like above, we have these strange effects:
When a comand is sent on the 5 byte writable characteristic, I not only get the correct reply on the 5 byte readable one as a notification.
I also get 4 unsolicited "notifications", or at least events from the API, each one of the 4 readable 20byte characteristics - but the data pointer points to NULL, and this comes passed to the Robotics API from the deep of iOS as far as I could see.
If the custom embedded device somehow violates the BLE specs, it would not be iOS' fault, of course.
Now, if I try to also send actual notifications on the 4 server-to-client 20 byte characteristics, none of the observed behavior changes, the real notifications do not get through, only the broken ones as before.
We do have a BLE sniffer, Perytons, with a bunch of USB BLE dongles.
We don't see "broken notifications" (whatever those might look like) or something there, but the sniffer also sometimes does not pick up things we clearly received, so it seems unreliable, and inconclusive whether the server does or does not send "broken notifications", or it's, for some reason, on the iPhone side.
Making the 20bytes characteristics also only 5 bytes small did not change the behavior. Changing their order in the GATT DB array to feed the magic broadcom "API" functions with also did not change anything.
The characteristics were generated using broadcom's generator plugin in the WICED IDE for that purpose.
Posting on the broadcom forum hasn't been fruitful so far.
Now - has anyone of you ever observed such behavior, and can point to possible causes?
Thanks very much in advance. I'm new to BLE and at my wits end here.