search

zephyrproject-rtos / zephyr

Primary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures.
https://docs.zephyrproject.org
Apache License 2.0
10.8k stars 6.58k forks source link

stm32wb BLE mac address derived from UID64 not working #56190

Closed Snevzor closed 1 year ago

Snevzor commented 1 year ago

Discussed in https://github.com/zephyrproject-rtos/zephyr/discussions/55825

Originally posted by **Snevzor** March 15, 2023 I'm on Zephyr v3.2.0 with stm32_hal v1.14.0 and with zephyr/samples/bluetooth/st_ble_sensor/ the BLE mac is **02:80:E1:00:00:00**. Looking in zephyr/drivers/bluetooth/hci/ipm_stm32wb.c I've checked that `LL_FLASH_GetUDN()` returns 8adbb9 and in the 'bt_ipm_set_addr' function param->value[0] to param->value[5] are printed as `**b9 db 8a 26 e1 80**` which is according to my expectations. I've looked into PM0271 - Rev 6 and AN5289 Rev 8 but haven't found anything out of the order. `bt_hci_cmd_send_sync(ACI_HAL_WRITE_CONFIG_DATA, buf, &rsp);` is then executed without errors but it seems the BLE stack is not using this new config data. When I read the address in the sample application using `bt_id_get` and `bt_addr_le_to_str` I also get `02:80:E1:00:00:00` instead of '80:E1:26:8A:DB:B9'. I'm using stm32wb5x_BLE_HCILayer_fw.bin because stm32wb5x_BLE_Stack_full_fw.bin is no longer compatible with Zephyr. I've also tested with fw versions 1.14.1, 1.15.0 and 1.16.0 as I thought this could be a fw bug, but I'm getting the same results. Am I missing something here? It used to work with the full fw stack (when I tested this more than a year ago). I know I'm not supposed to re-use these MACs from ST, but this sample code should work nonetheless, and having all the same MACs for multiple testing devices is a real pain. Also, with custom addresses the same HCI commands will have to be executed.
erwango commented 1 year ago

That might be due to the "late" HCI_RESET which is performed by the host stack. Ideally the local address has to be configured by the application side. bt_ipm_set_addr is a reliquish from a previous implementation which was performing HCI reset in the driver itself (earlier in the stack init process). It had the advantage of enabling some configuration within the driver itself, but it's a layer violation and has some drawbacks (such as the issue to get transparent mode working) If you're interested, you can do some archaeology in the driver history and find out more on previous implementation

Snevzor commented 1 year ago

Thanks for the fast response @erwango !

I'll try some stuff and look into the driver history.

erwango commented 1 year ago

ok, moving to discussion.