cancel
Showing results for 
Search instead for 
Did you mean: 

Conflict betwenn PKA and BLE after pairing.

MBuen.1
Senior

Hello guys,

I have a STM32WB application that runs bluetooth and PKA peripherals. We did setup this both peripherals a long time ago and was all going smooth. Our PKA is properly working using ISR, all the hardware semaphores were validated (including PKA Hw Semaphore) and running properly, BLE is perfectly communicating.

Until couple days ago we found a out a bug that, after a new device is paired to the STM32WB, in the following PKA operation, the ISR simply is not called. Without using the ISR the PKA generates a wrong result aswell.

During some debugging, i saw that after a pairing operation, the PKA Control Register assumes the value 0x2200, but i stil didn't find what this means.

If we reset the device, we didn't find any problem at all. We're able to communicate using BLE, use the PKA peripheral and everything works properly. Our only problem right now is after we pair a device and tries to use PKA right afterwards.

I'm using CubeMX V1.7, STM32WB SDK V1.13.1 and BLE Stack Full V1.13.1.

Is there something specific about the BLE pairing process that i could be missing? Perhaps some clock configuration?

Best Regards,

Matheus

1 ACCEPTED SOLUTION

Accepted Solutions
MBuen.1
Senior

I found the problem.

Basically the BLE pairing is a process that is a ECC Key exchange and involves cryptography.. long story short, the CPU2 uses the PKA peripheral during this process. The CPU2 disables this peripheral after using it (what is visible in the Control Register, since bit 0 is with value 0 after CPU2 usage).

All i needed was to use de EN_PKA_MASK in the PKA CR, and everything worked fine again =)

View solution in original post

1 REPLY 1
MBuen.1
Senior

I found the problem.

Basically the BLE pairing is a process that is a ECC Key exchange and involves cryptography.. long story short, the CPU2 uses the PKA peripheral during this process. The CPU2 disables this peripheral after using it (what is visible in the Control Register, since bit 0 is with value 0 after CPU2 usage).

All i needed was to use de EN_PKA_MASK in the PKA CR, and everything worked fine again =)