Missing IPCC enable for C2 in several examples

[tim-nordell-nimbelink]

These lines:

https://github.com/STMicroelectronics/STM32CubeWB/blob/master/Projects/P-NUCLEO-WB55.Nucleo/Applications/BLE/BLE_Ota/STM32_WPAN/Target/hw_ipcc.c#L185-L189

are missing from the following files:
P-NUCLEO-WB55.Nucleo/Applications/CKS/CKS_Crypt/STM32_WPAN/Target/hw_ipcc.c
P-NUCLEO-WB55.Nucleo/Applications/BLE/BLE_BloodPressure/STM32_WPAN/Target/hw_ipcc.c
P-NUCLEO-WB55.Nucleo/Applications/BLE/BLE_p2pClient/STM32_WPAN/Target/hw_ipcc.c
P-NUCLEO-WB55.Nucleo/Applications/BLE/BLE_p2pServer/STM32_WPAN/Target/hw_ipcc.c
P-NUCLEO-WB55.Nucleo/Applications/BLE/BLE_Custom/STM32_WPAN/Target/hw_ipcc.c
P-NUCLEO-WB55.Nucleo/Applications/BLE/BLE_TransparentMode/STM32_WPAN/Target/hw_ipcc.c
P-NUCLEO-WB55.Nucleo/Applications/BLE/BLE_HeartRate/STM32_WPAN/Target/hw_ipcc.c
P-NUCLEO-WB55.Nucleo/Applications/BLE/BLE_p2pRouteur/STM32_WPAN/Target/hw_ipcc.c
P-NUCLEO-WB55.Nucleo/Applications/BLE/BLE_Beacon/STM32_WPAN/Target/hw_ipcc.c
P-NUCLEO-WB55.Nucleo/Applications/BLE/BLE_HealthThermometer/STM32_WPAN/Target/hw_ipcc.c
P-NUCLEO-WB55.Nucleo/Applications/BLE/BLE_HeartRateFreeRTOS/STM32_WPAN/Target/hw_ipcc.c

That led me down a wild goose chase in a program I was writing that happened to be based on one of the examples that lacked that note. That note isn't in AN5185 either.

The note in the example is slightly wrong - it impacts sleep mode on CPU1 too. E.g. just a WFI without deep sleep enabled.

Thanks,
Tim

[ASELSTM]

Hi @tim-nordell-nimbelink,

Actually, these lines has been added internally but not yet released. The fix will be published in the frame of the future publication. We cannot share a date for the moment. Stay tuned and thank you once more for your contribution and for your patience.

With regards,

[tim-nordell-nimbelink]

Hi @ASELSTM -

I'm glad someone else at least spotted this.

One could argue that this is a bug in the FUS bootloader that the Cortex-M4 is compensating for by enabling peripherals that the FUS didn't enable access to. Granted, there probably aren't plans to release a new FUS bootloader unless a critical bug is found necessitating a new release of FUS, but ideally this flag would just be set inside the FUS code if there happens to be a new release of FUS at some point.

Thanks,
Tim

[ASELSTM]

ST Internal Reference: 87240

[ASELSTM]

Hi @tim-nordell-nimbelink

I hope you are fine. The issue you reported has been fixed in the frame of version v1.10.0 of the STM32CubeWB published recently on GitHub.

Thank you again for having reported.

With regards,