Using Different Pins to Control External BLE Power Amplifier

[MeSh_3749161]

Hi everyone!
We are equipping PSoC 6 with an external power amplifier/low noise amplifier (PA/LNA) . As PSoC 6 documents say, there are three specific dedicated pins to control an external PA/LNA : P7.4 and P7.5 (RX_EN and TX_EN). However, in top design we digitally connected them to P0.0 and P0.1 . (we are not using an external 32768Hz crystal and BLE is run by ILO.)
I am wondering whether this approach is acceptable or it might affect the quality of real-time audio data transfer over BLE.

[Owen_Zhang123]

It's better to use the dedicated pins for the external PA. If you use other pins, you can't use the internal API and need to control it with GPIO.

[MeSh_3749161]

Thanks for you reply. We connected the dedicated pins to other pins in top design:

The internal API is usable though. We are worries if this approach is affecting the quality of real-time audio data transfer over BLE.

[Owen_Zhang123]

It is OK as your design. I am just curious about it. Why you need to use P0.0 and P0.1 for PA control. For a easy layout? You need use four pins as your design.

[MeSh_3749161]

Well, yes, it is the matter of layout.  Yes, it took two more pins though. However, the only worry is whether this could make a problem for real-time audio data transfer over BLE.

[Owen_Zhang123 · Accepted solution]

The BLE data transfer is OK with your design. The design just connect another PIN to the dedicated PIN by hardware.

[MeSh_3749161]

As another but related question: do you think using ILO instead of PILO with a 32.768KHz crystal would make a problem for real-time audio data transfer over BLE?

[Owen_Zhang123]

I am not clear about your question. There are three sources for the low frequency clock: ILO, PILO, WCO. We recommend the WCO. You may also use PILO. ILO is not recommended because of the low precision.

[MeSh_3749161]

Well, we have a two-way audio data transfer via BLE. one way (master to slave) works fine but another way doesn't.
Can we infer that because one of two ways are working properly, it is not the matter of precision of ILO? 

[Owen_Zhang123]

Yes, I think the ILO is not the problem per your description.

You may need to capture some OTA log with a sniffer to analyse the root cause.

[MeSh_3749161]

Thanks. That's a good idea. But, in general, what would we miss in BLE communication by using ILO instead of PILO with an actual 32.768KHz crystal?

[Owen_Zhang123]

The CLK_LF is used in sleep mode during connection interval. If you use the ILO as CLK_LF, there may be some problem with connection stablity. But in your case, there are data loss in one way transfer. It doesn't look like clock problem, need more information to analyse it.

You can change it to PILO or test your project in the kit board with WCO to see if the problem still exists.