This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2642R: How to use the UART serial port on CC2642R, then switch to PTM mode to run TI API HCI_EXT_EnhancedModemTestTxCmd()

Part Number: CC2642R
Other Parts Discussed in Thread: CC2640, , SYSCONFIG

Hi Clément,
On our old MCU CC2640 we used successfully HCI_EXT_ModemTestTxCmd(HCI_EXT_TX_UNMODULATED_CARRIER, TEST_FREQUENCY_2440) to generate and test RF signal.
On our new MCU CC2642R + SDK SimpleLink CC13xx CC26xx [6.10.0.29], this HCI API does not work: locks up, does not return to the calling code. You helped me in the past to resolve this problem and run an API, all in ticket:
e2e.ti.com/.../4535375

The solution in this ticket was to use:
- API: HCI_EXT_EnhancedModemTestTxCmd(HCI_EXT_TX_UNMODULATED_CARRIER, 0, TEST_FREQUENCY_2440); // where 0 is for One_Mbps_Phy
- Also use PTM mode in sysconfig + NPI included in the CCS build, also to remove DEBUG from Compiler pre-defines: needed 'cos PTM is enabled and initializes the UART.

This solution was fine for our previous needs, but now we want to continue to use the UART serial port on CC2642R, and still transmit UNMODULATED_CARRIER on 2440 MHz. Can you suggest a solution for this task?
In PTM mode, if I try to run:
g_UartHandle = UART_open(Board_UART0, &g_UartParams);
I get 0 handle ('cos PTM has already opened the UART?), and the following API locks up:
(void)UARTCC26XX_control(g_UartHandle, UARTCC26XX_RETURN_PARTIAL_ENABLE, NULL);

I tried the following solution but had 2 undefined symbols MRDY_PIN, SRDY_PIN during the build process, in file npi_tl.c (will check them further):
NPI included in the CCS build: in tick box for folders on the left in CCS
Code sequence:
Debug_close(); // release UART
ret = HCI_EXT_EnablePTMCmd(); // to enable RF cmd execution
if (ret == HCI_SUCCESS)
{
   HCI_EXT_EnhancedModemTestTxCmd(HCI_EXT_TX_UNMODULATED_CARRIER, 0, EMC_TEST_FREQUENCY_2440); // 0 -> One_Mbps_Phy
. . .
------------------
Any suggestions are very welcome.

  • Hi Ludmil,

    Long time no talk :)

    Thank you for the clarity of the problem description.

    May I ask you to specify whether it is important to use the same UART module and the same pins to control the PTM and the other UART serial communication?

    If not, then it sounds like using the second UART interface for the other UART serial communication would probably the easiest.

    If yes, then I would suggest to close and re-open the UART.

    I hope this will help,

    Best regards,

  • Hi Clément, Thank you for your advice. I prefer to use the same UART and can carry on with closing the UART, but noticed another solution on this forum:

    CC2642R: HCI_EXT_EnhancedModemTestTxCmd hangs in SDK 4.20.00.35 - Bluetooth forum - Bluetooth®︎ - TI E2E support forums

    You recommended an addition of the compiler predefined symbol "HCI_TL_FULL". I tried this in combination with the API:
    HCI_EXT_EnhancedModemTestTxCmd(HCI_EXT_TX_UNMODULATED_CARRIER, 0, EMC_TEST_FREQUENCY_2440);     // LK: 0 -> One_Mbps_Phy

    and this API did not lock up (it locks without the symbol). I am planning to check the 5dBm RF power on the above frequency using an RF meter by the end of this week.
    I hope that this simple solution will work for the main purpose to transmit 5dBm, and I will not have any side effects because of the predefined symbol.

    Best Regards

    Ludmil

  • Hi Ludmil,

    Good point! This approach should also do the trick!

    Let us know how it goes.

    Regards,

  • Hi Clément, I used the compiler predefined symbol "HCI_TL_FULL" in combination with the API:
    HCI_EXT_EnhancedModemTestTxCmd(HCI_EXT_TX_UNMODULATED_CARRIER, 0, EMC_TEST_FREQUENCY_2440);     // 0 -> One_Mbps_Phy

    I see consistent 2440 MHz within an acceptable range on an RF handheld analyzer, but the power level is a bit low: around -75 dBm. The API is supposed to transmit at max cc2642R RF power which is 5dBm.I see attenuation that is 2 times bigger than the one I expect, comparing with RSSI provided by mobile apps during BLE5 advertising and connection for such very close distance, so I will be testing again in a more accurate setup very soon. 

  • Hi,

    Thank you for telling me.

    Here are a few elements to consider in order to get to a better understanding of the issue:

    • Check if setting the TxPower has an impact (use HCI_EXT_SetTxPowerCmd)
    • Check if the same reduced TxPower is reproducible when using the unmodified host_test example with BTool
    • Check the power consumption of the device while transmitting the continuous tone - compare it to the power consumption announced in the datasheet for the same

    Best regards,