• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 51 subscribers
  • Views 561 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.

CC2541: CC2541 with PA only uses TX and RX

Alex Zhang
Intellectual 1305 points

Part Number: CC2541
Other Parts Discussed in Thread: CC2590

There are several questions regarding the programming of CC2541 and PA (protocol stack version 1.3.2)

1. In the protocol stack of HCI_EXT_ExtendRfRangeCmd ，Has this HCI instruction set all three pins of （P1_1、 P1_2、 P1_3） by default？

Because our hardware design only incorporates P1_ 2 and P1_ 3 for PA，The (P1_1) pin is used for buttons, so it will be set to pull up the input to detect the falling edge.

So I would like to ask how to configure the corresponding registers for RF using only these two pins (P1_2, P1_3).

2.Will the macro (HAL_PA_LNA_CC2590) in the command line affect the setting of PA if not enabled (only using the P1_2 and P1_3 pins).

3.Is it necessary to set (P1_2, P1_3) to normal IO and set it to low level to keep the PA chip in a low-power state without executing the instruction (HCI_EXT_ExtendRfRangeCmd ) and disabling the macro (HAL_PA_LNA_CC2590) when entering low-power. What special register configurations are required to set these two pins (P1_2, P1_3) from the RF observation mapping pin to normal IO.

4.The protocol stack will operate on the (P1_1) pin when enabling PA function. However, the (P1_1) pin is used for key detection on our hardware. There are two ways to ensure that the two do not affect each other. Method B has not yet been implemented. It is necessary to confirm the configuration values of these two registers (RFC_BBS-CTRL0, RFC_BBS-CTRL1).

A. The current way to deal with this problem is to call the instruction {hciStatus_t HCI_EXT_ExtendRfRangeCmd (void)} and then call the instruction {hciStatus_t HCI_EXT_SetRxGainCmd (uint8 rxGain)}. The entry parameter is: (HCI_EXT_RX_GAIN_HIGH). Then I observe that (P1_1) is set as output and high level. Then I set (P1_1) as input and use it to detect the falling edge. There has been no phenomenon of program instructions pulling down (P1_1) during program operation. Perform the above steps again after the program transitions from sleep state to wake-up state. Currently, there have been no abnormal phenomena during testing. But I am not sure if the transmitter output power setting will return to the default value of 0 dBm when DTM ends by calling (HCI_LE_TestEndmd) or (HCI_Reset). This situation can lead to a falling edge inside the program at the (P1_1) pin. It is not the falling edge generated by external buttons that causes the program to run incorrectly.

B. I have another expected solution to this problem is to directly configure the register to only configure the (P1_2, P1_3) pins as PA function pins, and then configure the (P1_1) pin as a normal input pin for detecting buttons. But I found that:

RFC_ OBS_ CTRL0 = 0x68;

RFC_ OBS_ CTRL1 = 0x6A;

Can you provide some opinions on whether the two methods are reasonable.

  • 0
    TI__Guru** 101540 points

    Hi,

    This query will require us some investigation. Please expect some feedback on the week of May 1st.

    Thank you for your comprehension.

    Best regards,

  • 0 in reply to Clément
    TI__Guru** 101540 points

    Hi,

    I am about to start working on this query.

    May I kindly ask you if you have new elements to share?

    Bets regards,

  • 0 in reply to Clément
    TI__Intellectual 1305 points

    Question 1: The protocol stack operates the P1_1 pin while enabling the PA function, however P1_1 pin is used for key detection on our hardware. There are two ways to do this without affecting each other. Mode B has not yet been implemented. You need to confirm what the configuration values are for RFC_OBS_CTRL0 and RFC_OBS_CTRL1 registers.

    A, my current handling for this issue is to call hciStatus_t HCI_EXT_ExtendRfRangeCmd first (Void) This directive is then called hciStatus_t HCI_EXT_SetRxGainCmd (uint8 rxGain) The entry parameters are: HCI_EXT_RX_GAIN_HIGH At this point I noticed that P1_1 was set to output and high, and then I set P1_1 to input and used it to detect the falling edge. There is no indication that the P1_1 is lowered by a program instruction during the program operation. Redo the above steps after the program goes from hibernate to wakeup. No anomalies have been detected in the current test. But I can't be sure when it comes up: When the DTM ends by calling HCI_LE_TestEndCmd or HCI_Reset, the transmitter output power setting returns to the default value of 0 dBm. This will cause the program to have a drop edge inside the P1_1 pin. Instead of a falling edge caused by an external key, the program runs incorrectly.

    B, I have another way to think about this problem is to configure only P1_2, P1_3 as the PA function pins via the direct configuration register and then configure P1_1 as the normal input pins for the detection of the keys. But I found:

    RFC_OBS_CTRL0 = 0x68;
    RFC_OBS_CTRL1 = 0x6A;

    Question 2: Could you give some opinion as to whether the two approaches are reasonable? 

  • 0 in reply to Alex Zhang
    TI__Intellectual 1305 points

    Also, if you use DD, DC here are two pins as normal IO, there is no risk, such as going into debug mode by mistake 

  • 0 in reply to Alex Zhang
    TI__Guru** 101540 points

    Hi,

    The approach followed is not standard and has not be thoroughly tested on our side. In addition, we recommend to use P1_1 as PA pin as it has 20-mA drive capability.

    Please refer to the CC254x User's Guide (https://www.ti.com/lit/swru191), part's data sheet (https://www.ti.com/lit/ds/symlink/cc2540.pdf) and the reference designs published.

    Best regards,