Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BLE112 reboot after scanning few packets #32

Open
sridharrajagopal opened this issue Dec 1, 2016 · 4 comments
Open

BLE112 reboot after scanning few packets #32

sridharrajagopal opened this issue Dec 1, 2016 · 4 comments

Comments

@sridharrajagopal
Copy link

sridharrajagopal commented Dec 1, 2016

Hi,

I'm trying to implement a BLE master to read data from a custom BLE device, and am trying to run the BGLIB_scanner demo to scan for the device.

I notice that after scan response from the device of a few packets, I see a "system boot" message, which indicates that the ble112 device restarted?

I have tried the scanner with a TI Sensor Tag and it can read scan responses all day long.

The only difference I see with this device is that the address type is "1" (random) (whereas the TI Sensor Tag has an address type of "0" (public) ).

I'm wondering if there is anything different in the code path in the device/library for address type of "1", where there might be a bug or issue?

Output from BGLib_scanner demo is shown below:

Thanks,
Sridhar

������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������BLE112 BGAPI Scanner Demo
Operations Menu:
0) Reset BLE112 module
1) Say hello to the BLE112 and wait for response
2) Toggle scanning for advertising BLE devices
Command?
-->	system_hello
<--	system_hello
-->	system_reset: { boot_in_dfu: 0 }
###	system_boot: { major: 1, minor: 4, patch: 2, build: 82, ll_version: 3, protocol_version: 1, hw: 1 }
-->	system_reset: { boot_in_dfu: 0 }
###	system_boot: { major: 1, minor: 4, patch: 2, build: 82, ll_version: 3, protocol_version: 1, hw: 1 }
-->	gap_set_scan_parameters: { scan_interval: 0xC8, scan_window: 0xC8, active: 1 }
<--	gap_set_scan_parameters: { result: 0 }
-->	gap_discover: { mode: 2 (GENERIC) }
<--	gap_discover: { result: 0 }
###	gap_scan_response: { rssi: -49, packet_type: 0, sender: 3C1F4932ACF7, address_type: 1, bond: FF, data: 0201050D09536D617274204D6F64756C65 }
###	gap_scan_response: { rssi: -49, packet_type: 4, sender: 3C1F4932ACF7, address_type: 1, bond: FF, data: 110700000000000000B00040510421AA00F0 }
###	gap_scan_response: { rssi: -49, packet_type: 0, sender: 3C1F4932ACF7, address_type: 1, bond: FF, data: 0201050D09536D617274204D6F64756C65 }
.....
###	gap_scan_response: { rssi: -48, packet_type: 0, sender: 3C1F4932ACF7, address_type: 1, bond: FF, data: 0201050D09536D617274204D6F64756C65 }
###	gap_scan_response: { rssi: -49, packet_type: 4, sender: 3C1F4932ACF7, address_type: 1, bond: FF, data: 110700000000000000B00040510421AA00F0 }
###	gap_scan_response: { rssi: -49, packet_type: 0, sender: 3C1F4932ACF7, address_type: 1, bond: FF, data: 0201050D09536D617274204D6F64756C65 }
###	gap_scan_response: { rssi: -49, packet_type: 4, sender: 3C1F4932ACF7, address_type: 1, bond: FF, data: 110700000000000000B00040510421AA00F0 }
###	gap_scan_response: { rssi: -48, packet_type: 0, sender: 3C1F4932ACF7, address_type: 1, bond: FF, data: 0201050D09536D617274204D6F6475801C }
###	system_boot: { major: 6, minor: D0, patch: 1F3C, build: 3249, ll_version: F7AC, protocol_version: 1, hw: FF }

The interesting thing is that the system_boot message at the end shows a different major/minor versions than the initial message.

@jrowberg
Copy link
Owner

jrowberg commented Dec 1, 2016

A remote advertising device's address type should have no impact at all on the scanning device, and should certainly not be able to trigger a reset. There is nothing in the code that would do this intentionally, since the scanner is only scanning and not attempting to connect or anything like that.

However, I suspect that the device is not actually rebooting, but the parsed data is getting misaligned somehow. All of the reported event arguments for the system_boot event are completely invalid: major, minor, patch, build, and ll_version are outside of real values that the system_boot event would report (and, indeed, did report higher up in the output). Further, you can see that the sender MAC address (3C1F4932ACF7) is actually broken apart into the patch, build, and ll_version fields.

I would monitor the actual serial RX/TX lines to see whether the data coming out of the module is valid (it probably is), and try a lower baud rate such as 9600. The Arduino has trouble with SoftwareSerial and faster baud rates.

@sridharrajagopal
Copy link
Author

Thanks for the prompt reply!

Yes, it certainly looks like some misaligned data. One other data point I have - the device stops scanning after a while (and shows the system_boot response), but when I start advertising with another device, say the SensorTag, then it does continue to process scan responses, including ones from the custom device. When I stop the SensorTag from advertising, then processing stops for both. I also see some interesting address types, which also seem to corroborate your theory of misaligned data.

I am using your BGLib_U1A1P_38400_noflow_wake16 firmware, and have set the baud rate to 38400 consequently (and using SoftwareSerial).

Would it be sufficient to set the SoftwareSerial baud rate to 9600 in the sketch, or would I have to update the BLE112 firmware as well?

Thanks,
Sridhar

@jrowberg
Copy link
Owner

jrowberg commented Dec 1, 2016

You would also need to reflash the module in order to change the baud rate there. It doesn't support auto-baud detection.

@sridharrajagopal
Copy link
Author

Hi Jeff,

I reflashed the module with the lower baud rate (9600), and adjusted the sketch to use that speed - it didn't seem to make any difference - I get the same behavior.

I wonder if it is a race that is triggered by the timing of the custom device.

Thanks,
Sridhar

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants