Making CoPro firmware opensource

[Alessio Galliazzo]

Hi guys,

Do you ever had a thought about making the CoPro firmware opensource and allow the community to participate the development?

I see that the progress in maintining the Thread protocol is quite slow compared to the Openthread main repos, also some bugs I found during development could already be closed by myself if I only had the CoPro sources.

For example, a problem on the DNS subsystem is in your github issues page since 1 month, maybe I can had solved that problem in the meanwhile and share the solution with other guys. I'm not questioning about the delay, I can understand that not all developer in ST can work on every topic. This is the exactly reason why I'm suggesting the opensource approach.

Best

Alessio

[Remi QUINTIN]

Hi Alessio

Our secure architecture prevents any open-source strategy as the stack needs to be encrypted with specific ST key to be program via dedicated firmware update services ( FUS).

This means you would not be able to use/develop the source code to flash it afterwards.

We are aware of the DNS issue you are facing as you logged your question via another post on this community. We are trying to answer you asap.

[Alessio Galliazzo]

Dear Remi,

Thanks for the answer, this is a very sad news.

The problem is not the DNS issue itself, it's all the system: without source code we cannot compile the Openthread stack with different flags, also we cannot be up to date with the latest bugfix in the development branch of Openthread and, of course, we are subjected to delay caused to bugs.

For example, the DNS bug is 1 month old, and for 3 weeks in the todo list without any reply. for the SHCI_C2_FLASH_StoreData (SHCI_C2_FLASH_StoreData not supported feature · Issue #74 · STMicroelectronics/STM32CubeWB · GitHub) things seems going better but package releases seems to took few months.

Also, and this is my personal opinion, it seems that testing the stack is not carefully done (maybe this is due to the fact that Thread stack is less used than BLE or Zigbee, I don't know): the issue 74 make the stack not usable and not compliant with Thread specification as stated by the OpenThread team on SRP Client Key and name conflicts · openthread openthread · Discussion #8864 · GitHub.

Should a more opensource-like approach with, maybe, a development branch and a CI/CD deployment and a community based testing/issue report be more usefull for your product?

Best

Alessio