• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 52 subscribers
  • Views 717 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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: HCI_EXT_EnhancedModemTestTxCmd hangs in SDK 4.20.00.35

Alexander Wenner
Intellectual 420 points
Part Number: CC2642R

Hi.

We have recently migrated to SDK 4.20.00.35 and the code to help our hardware developer to optimize our antennas seems to no longer be working.

Essentially we added the following lines of code to the simple_peripheral project "SimplePeripheral_init" method after the ICall intialisation:

HCI_EXT_EnhancedModemTestTxCmd(HCI_EXT_TX_UNMODULATED_CARRIER, HCI_EXT_RF_SETUP_1M_PHY, 0);
return;

Using SDK 3.40.00.02 this had the desired effect of setting the radio to emit the correct signal. In SDK 4.20.00.35 (and 4.20.01.04) the execution hangs during the call to HCI_EXT_EnhancedModemTestTxCmd. I'm propably just missing some new configuration option but I've been looking through the documentation but can't seem to find it. Do you have any pointers?

Sincerely,

Alex

  • 0
    TI__Genius 14845 points

    Hi Alexander, 

    Assigning an expert to follow-up. 

    Thanks, 
    Elin

  • 0
    TI__Guru** 101460 points

    Hi,

    Can you verify if the device enters the ROM_Spinlock() function? (this function is in rom_init.c)

    If yes, then the issue is probably due to some missing pre-defined symbols at building time an adding the symbol "HCI_TL_FULL" should solve the problem.

    Best regards,

  • 0 in reply to Clément
    Intellectual 420 points

    Good morning.

    The device did indeed enter the ROM_Spinlock() function and adding the "HCI_TL_FULL" pre-define seems to have solved the problem. Thank you.

    A only slightly related further question: Is the call to HCI_EXT_EnhancedModemTestTxCmd supposed to change GPIO pin states? We are seeing some unexpected changes on DIO4 and DIO5. This is not a real problem because it can be easily remedied by resetting the states after the call, but would be interesting to know.

    Sincerely,

    Alex