2 of 2 people found this helpful
All initial firmware must be loaded via the HCI UART. Subsequent updates can be loaded via the PUART and there is an application in the SDK that can be used. Unfortunately, the minidriver spec/source code is not available for distribution (even with an NDA/SLA), and the minidriver itself is the only way to load firmware over the HCI UART.
There are tools/methods described here on the forum that can be used for programming, but admittedly, they would be cumbersome for large scale mass production. For that, Avnet now provides programming services through one of their programming partners. I believe there is also a distributor in Asia that can provide a similar service, but I do not have any information on the specific engagement criteria.
Looks like we have to accept that or change module. Dealing with extra production steps and maintaining them is always cumbersome and not cost efficient.
I don't see why the HCI protocol shouldn't be available for customers. It doesn't discloses nothing special about your module. On the other side it complicates production for your customers a lot.
Thanks for the quick reply !
Hi mapac_2161196 You have valid points that Broadcom should consider for future SDK rollouts - IMHO.
The problem is not so much the protocol being proprietary for Broadcom, it's a matter of supporting it, and deploying changes to it. For example, right now, Broadcom can simply change ANY part of the protocol, perform its due diligence during System Verification Testing on the new tool(s) and release the new version in an upcoming SDK. Pretty simple (for Broadcom)...
If the minidriver update process were documented for the public to consume, not only would the documentation have to be updated to compensate for the new changes (easy), but a whole new slew of considerations of what is "out in the field" and how to be backwards compatible with it have to be considered during the testing phase (hard).
I'm not saying Broadcom shouldn't document it, only that keeping the process 'secret' has its merits for them.
I totally agree that knowing the HCI protocol would simplify manufacturing and enable field upgrade from an attached CPU.
Why would Broadcom create this roadblock?
1 of 1 people found this helpful
I have checked again with the Bluetooth development team and can confirm again that the source code for the minidriver cannot be made available. As my colleague Michael advised on the earlier forum post, there are two options for programming:
1. Using the command line tools as described in the forum
2. Using a mass programming service such as those available from Avnet or BP Micro.
I understand this is not the answer you were hoping for but these are the only options we can offer.
I wouldn't expect source for the minidriver, but details of the HCI protocol used by ChipLoad would be helpful.
For example, writing to memory seems to take the form of "01 4c fc <length of data to write (1 byte)> <data>". Is this documented?
It's a fair question but we cannot provide access to this driver, or provide any documentation on how this closed module works either.