Bluetooth not Initializing at Rpi Zero W

[moahrs]

Hi,

First, sry for my english... I will be more clear possible.

I am using u library in my projetct, where i am using Rpi Zero W with a TFT with Touch. All is working fine, but the bluetooth not. He is in a infinit looping at "boolean CBTSubSystem::Initialize (void)", the line(s) below:

while (!m_HCILayer.GetDeviceManager ()->DeviceIsRunning ()) { CScheduler::Get ()->Yield (); }

I am verify and is here... the process stops and stay here. I am analised u code, but i think u can helpme better.

Ty a lot.
Moacir Jr.

[rsta2]

It seems the Circle BT support is not working on the Zero W. The firmware does not respond. I do not have a Zero W and the BT support has never been tested there. It is working on the RPi 3B. But because the Circle BT support is only rudimentary and cannot be extended for legal reasons, I will not work on this again. I'm sorry.

I will disable the Circle BT support for the internal controller on the Zero W, so that an external controller can be used.

[moahrs]

Rsta2, HI...

Can i try to fix it? And i send to you if work?

[rsta2]

Are you sure, this will help you? The Circle BT support is rudimentary. It can do a device inquiry only. There is no pairing or data connections possible with it. Furthermore you have to be a member of the Bluetooth SIG to be allowed to use the BT specs.

If this is all the case, you can try it. It's likely that you have to load a different firmware. Please branch off from the develop branch and revert the commit acf3c74, because it disables the Zero W Bluetooth support.

[moahrs]

I think yes... I do comunication with BT of the Rpi Zero W, using BT core documentation. I send many commands, receive some replies, but the inquiry i cant success, and your BT from circle, is the most complete lib of bluetooth withou linux (for pure baremetal) that i founded. If u know someone more better, i apreciate, but i think in try to fix it.

Only one question: i see and try to understand class/methods and etc about that code that not work in zero w. But u can explin, if u can of course, in less words, or many rsssss (is better), what that code do? I try to comment that code, but the inquiry not reply in the 20s, for sample, he stay infinity waiting for reply.

Ty a lot
Moacir Jr.

[rsta2]

Unfortunately it's not that easy. Have you read the disclaimer of the BT Core specs? Your employer has to be a member of the BT SIG (Special Interest Group) so that you can use these specs. If this is not the case, I cannot support you. The BT support in Circle will not be continued and I will not include any BT related updates into Circle from users, which are not allowed to use these specs. You may have a look at this project, but I don't think it is working with the RPi Zero W and its legal status is unknown.

[moahrs]

Ty Ty.. i understand.. i wil see these points, and this project...

ty a lot for now...
Moacir Jr.

[moahrs]

Man, I DO IT.. its working in Pi Zero W.... UHUUUUUUUUUU.. rssssss.. i am vry happy...
The problem, was the converttool.c, in the command to open file, was only with "r", need to be "rb". Only with "r", the EOF read 0x1a as "EOF Text File", then he reading wrong. When i put "rb", the circle BT read all file with success, and the initialization and inquiry works like a charm.. \o/...

PS: I am working in windows 10, using gcc from MinGW for this compiler converttool. I do not know if gcc for openfile have diferences between gcc linux and MinGW.

[rsta2]

This was probably not easy to find. Thanks! I have updated converttool.c on the develop branch and reverted the commit acf3c74. converttool.c is also used in sample/21-webserver. I did not find this issue, because on Linux the "b" mode letter is optional.

[rsta2]

The update to the converttool is on master branch now. So this can be closed.

[Matheus-Garbelini]

Hi @rsta2, is the requirement to be a member of SIG to use the spec. applied even for open source projects?

[rsta2]

@Matheus-Garbelini I do not know an exception from the SIG membership rule for open source projects.

[Matheus-Garbelini]

@rsta2 you may like to check then

• InternalBlue (hacks this Broadcom ram patch mechanism to send arbitrary LMP packets),
• btlejack (Implements a malicious Link Layer to hijack & sniff peripherals)
• BLESuite (Implements a BLE stack in python),
• SweynTooth (Implements a raw Link Layer controller to send arbitrary packets).

It does not appear that circle would face legal issues given the current status of open source projects. The disclaimer seems applicable for commercial applications that may be infringing the SIG IP.

[rsta2]

@Matheus-Garbelini I cannot talk about other open source project, which may be more important than Circle or may have special agreements, which I do not know. The disclaimer of the Bluetooth core specification is very clear in that: Using it without being a member of the Bluetooth SIG is prohibited.

[dariusc93]

IANAL but what I can tell you is that you dont need to be a member of BTSIG to develop software against hardware thats already certified by BTSIG (in this case, the raspberry pi). You do need to be a member if you plan on developing and sell your own bt hardware and go through qualification and testing for it to be certified and be able to use their trademark with said hardware. There are plenty of individuals and companies that develop software only for bluetooth devices (directly or indirectly) already out there without being members. If youre still not sure then its probably best to play it safe until you can get full confirmation.

[Matheus-Garbelini]

@rsta2 @dariusc93 If that helps I myself disclosed SweynTooth vulnerabilities and made available a BLE link layer implementation there. When contacting SIG, everything was still fine. My understanding is aligned with @dariusc93.
In my opinion and experience, if the wording presented on the spec disclaimer would be followed 100%, then no current BT research can be done as researchers need to use the spec in some way or another.

If @rsta2 didn't receive a taken down from SIG due to commercial reasons, there's no reason to apply it here. This is also the case when comparing with InternalBlue which not only reverse engineered Broadcom diagnostics protocols, but created patches to enable BT sniffing on multiple third-party hardware. Clearly, they have used the spec as myself.

[rsta2]

@dariusc93 I do not question the right to develop software for any BT device, certified or not. I question, if it is legal to use the BT core specification without being a member of the BTSIG. If I take the disclaimer in this specification into account, it is not legal. Maybe somebody is able to develop BT software using other sources. I'm not able to do this.

@Matheus-Garbelini Maybe a number of researchers have a special deal with the BTSIG to be allowed to use its specifications. Even if some people are using them without being a member or without a special deal, this does not mean that it's legal.

I see only two possibilities for having BT support in Circle: A reliable source (maybe a BTSIG person, who wrote at the public Internet), which confirms, that using the BT core specification is legal, without being a member of the BTSIG, for open source software or for whatever under which requirements. Or somebody, who develops this support on behalf of a firm, which is a member of BTSIG and can confirm, that he is allowed to do so.

[probonopd]

I think i is safe to assume that either Raspberry Pi Trading Ltd. or their supplier of the Blutetooth module/chip on the device is a member of the BTSIG. They are advertising "Bluetooth" (using that name) on their packaging, would probably long have been sued if they weren't. Merely writing software that uses that hardware (hopefully) doesn't require separate permissions; otherwise one probably couldn't hack on the BT code in Linux or FreeBSD either.

My use case would be MIDI over Bluetooth, which apparently is something that even pros use nowadays.