TC321x — using the TPLL 2.4G driver from the Single Connection SDK in a Multi...

Alex Kafando

Hello, **We are migrating a TC3215F product firmware from tc\_ble\_single\_sdk v3.4.3.0 to tc\_ble\_sdk v4.0.2.5**, because we need BLE functions, only supported by the SDK ‘multi’. The product also uses the proprietary 2.4G TPLL protocol. tc\_ble\_sdk provides no 2.4G support. We found that in tc\_ble\_sdk, liblt\_tc321x.a contains a tpll.o of 806 bytes defining no TPLL\_\* symbol, while tc\_ble\_single\_sdk ships the real driver (14156 bytes) in a separate library, liblt\_2p4g.a. We extracted tpll.o from liblt\_2p4g.a and linked it, together with ext\_rf\_private\_precompiled.o, into our tc\_ble\_sdk project. Its 17 undefined symbols are all resolved by tc\_ble\_sdk itself: RF\_Pri\_TPLL\_Init, \_\_modsi3 / \_*umodsi3, and 14 rf*\* functions from drivers/TC321X. No SDK file is replaced. The firmware builds, and the 2.4G link works against products still running the original single-SDK firmware. Our questions: 1. Is this approach acceptable from your side? 2. Are the rf\_\* driver functions binary-compatible between the two SDK versions? Could a future change break this silently? 3. Any expected side effect once a multi-connection BLE stack runs alongside this driver, regarding radio time sharing or power management? 4. Is 2.4G support planned for tc\_ble\_sdk? Its absence currently forces this workaround for any product combining proprietary 2.4G and multi-connection BLE. Best regards,