HCI firmware upgrade specs needed

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

Hello,

We have a system with the BCM20737S module. The module is connected to the host CPU via the PUART and HCI uart. The host cpu is running some custom embedded SW - no windows and no linux.

We were hoping we could do a firmware upgrade via HCI port, but I'm reading the HCI protocol specs are not available for public use. This is a real drawback as it requires a extra step in production to program the device via tools provided by the SDK. We were hoping is to ship our host cpu firmware that includes the firmware for the BLE module and program it in filed via the HCI port. This is also needed as we are doing remote firmware upgrades as the host cpu is connecting via WIFI to a remote server.

I'm kindly asking you to provide a strategy to minimize production steps (to none if possible) and have a functional remote FW upgrade possibility via the host CPU. We can sign a NDA if necessary.

Thanks, Marko

0 Likes
1 Solution
MichaelF_56
Moderator
Moderator
Moderator
250 sign-ins 25 comments on blog 10 comments on blog

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. 

View solution in original post

7 Replies
MichaelF_56
Moderator
Moderator
Moderator
250 sign-ins 25 comments on blog 10 comments on blog

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. 

Anonymous
Not applicable

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 !

Marko

0 Likes

Hi pangma01  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.

0 Likes
Anonymous
Not applicable

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?

0 Likes
Anonymous
Not applicable

Hello,

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.

Regards
Dave

Anonymous
Not applicable

Hi Dave,

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?

Thanks,

John

0 Likes
Anonymous
Not applicable

Hi John,

It's a fair question but we cannot provide access to this driver, or provide any documentation on how this closed module works either.

Regards

Dave

0 Likes