CC2650 and CC2592 control timing

Hi Fredrik,

Now I assume the CC2650 control the CC2592 IO are:

PA_EN is on DIO7

LNA_EN is on DIO13

HGM is on DIO9

and I just put the these GPIO initial in 

C:\ti\simplelink\ble_cc26xx_2_00_00_42893\Projects\ble\SimpleBLEPeripheral\CC26xx\Source\Application\main.c

What I did that like below:

#include <inc/hw_ioc.h>

#define Board_HGM_PIN IOID_9

PIN_Handle HGM_Handle;

void HGM_io_init(void) {
PIN_State keyPins;
PIN_Config keyPinsCfg[] =
{
Board_HGM_PIN | PIN_GPIO_OUTPUT_EN | PIN_GPIO_HIGH | PIN_PUSHPULL,
PIN_TERMINATE
};
HGM_Handle = PIN_open(&keyPins, keyPinsCfg);
}

void CC2592_io_init (void){
// Map RFC_GPO0 to DIO13
IOCPortConfigureSet(IOID_13, IOC_PORT_RFC_GPO0,IOC_IOMODE_NORMAL);
// Map RFC_GPO1 to DIO7
IOCPortConfigureSet(IOID_7, IOC_PORT_RFC_GPO1,IOC_IOMODE_NORMAL);
HGM_io_init();
}

Void main()
{
  PIN_init(BoardGpioInitTable);

  //enable iCache prefetching
  VIMSConfigure(VIMS_BASE, TRUE, TRUE);

  // Enable cache
  VIMSModeSet(VIMS_BASE, VIMS_MODE_ENABLED);

  #ifndef POWER_SAVING
  /* Set constraints for Standby, powerdown and idle mode */
  Power_setConstraint(Power_SB_DISALLOW);
  Power_setConstraint(Power_IDLE_PD_DISALLOW);
  #endif // POWER_SAVING

  CC2592_io_init();//I put this init before any Task init. Does it right?


/* Initialize ICall module */
ICall_init();

/* Start tasks of external images - Priority 5 */
ICall_createRemoteTasks();

/* Kick off profile - Priority 3 */
GAPRole_createTask();

SimpleBLEPeripheral_createTask();

#ifdef FEATURE_OAD_BIM
{
uint8_t counter;
uint32_t *vectorTable = (uint32_t*) 0x20000000;
uint32_t *flashVectors = &__vector_table;

// Write image specific interrupt vectors into RAM vector table.
for(counter = 0; counter < 15; ++counter)
{
*vectorTable++ = *flashVectors++;
}
}
#endif //FEATURE_OAD_BIM

/* enable interrupts and start SYS/BIOS */
BIOS_start();
}

and when and where I should control Board_HGM_PIN  by manually.

Because the CC2592 has these mode:

PA_EN     LNA_EN     HGM         Mode of Operation
0                0                 X               Power Down
X               1                 0                RX Low-Gain Mode
X               1                 1                RX High-Gain Mode
1                0                 X               TX

Thanks

Hi Fredrik,
I was misunderstanding the HGM pin means,
Now I realize the HGM pin.

Thanks a lot

Hi Fredrik, team,
After these 3 lines are configured, user just need to call HCI_EXT_ExtendRfRangeCmd(), then BLE stack can control CC2592 automatically (depending BLE Rx or Tx activity), right ?
Besides, is the characterization data for power table optimized ?
Could we use SmartRFStudio to perform RF test on CC2640+CC2592 ?

Hi Jerry,

Currently there is no ExtendRFRange command. Configuring the pins is all you have to do. There is no power table or RSSI correction as of now, that will be supported later.

Range extender is not supported in SmartRF Studio yet.

Best regards,
Fredrik

Hi Fredrik K
According to your last post, you mean Currently there is no ExtendRFRange command.
But CC2650 + 2592 the TX and RX power still has enhance fun now. Does it right.
Because I measure the CC2650 and CC2592 total power consumption is same the CC2650 only 0.6mA~0.8mA.
But the CC2650 and CC2592 work right now. Does anything I should setting or just control pin setting only.

Thanks

Hi Vincent,

Sure, using CC2650 with CC2592 will work fine as long as you have set up the IOs correctly.

The BLE stack does not know that CC2592 is connected though, so there is no correction for TX power settings and RSSI. This will come some time later this year.

Cheers,
Fredrik,

Hi Fredrik,

Ok I got it.

and the IO is setting ok and work right.

but the CC2650 and CC2592 total power will same with CC2650 only now, does it right?

Sorry ask this again, I just want to make sure this and I can wait for this fun in stack coming in the other days.

Thanks

The power consumption will be way higher. The CC2592 running at full power will consumer around 150 mA.

Hi Fredrik K,
Ok, I got it
and I will check the HW sch.

Thanks a lot

Hi Fredrik K,
I try many time the CC2650 control CC2592 is fine but the power consumption still low and not around 150mA.
What should I check again.

Thanks

Vincent,

Please provide a trace of the control signals and the schematic, without this it is hard to say what might be wrong.

Regards,
Svend

Hi Svendbt,

The GPIO define is like below:

#include <inc/hw_ioc.h>
#define Board_HGM_PIN IOID_12
PIN_Handle HGM_Handle;
void HGM_io_init(void) {
PIN_State keyPins;
PIN_Config keyPinsCfg[] =
{
Board_HGM_PIN | PIN_GPIO_OUTPUT_EN | PIN_GPIO_HIGH | PIN_PUSHPULL,
PIN_TERMINATE
};
HGM_Handle = PIN_open(&keyPins, keyPinsCfg);
}

void CC2592_Enable(void)
{
HGM_io_init();
IOCPortConfigureSet(IOID_13, IOC_PORT_RFC_GPO0,IOC_IOMODE_NORMAL);
IOCPortConfigureSet(IOID_14, IOC_PORT_RFC_GPO1,IOC_IOMODE_NORMAL);

//HCI_EXT_SetMaxDtmTxPowerCmd(HCI_EXT_TX_POWER_MINUS_21_DBM);
}

static void SimpleBLEBroadcaster_init(void)
{
// ******************************************************************
// N0 STACK API CALLS CAN OCCUR BEFORE THIS CALL TO ICall_registerApp
// ******************************************************************
// Register the current thread as an ICall dispatcher application
// so that the application can send and receive messages.
ICall_registerApp(&selfEntity, &sem);

// Hard code the DB Address till CC2650 board gets its own IEEE address
//uint8 bdAddress[B_ADDR_LEN] = { 0x33, 0x33, 0x33, 0x33, 0x33, 0x33 };
//HCI_EXT_SetBDADDRCmd(bdAddress);

// Create an RTOS queue for message from profile to be sent to app.
appMsgQueue = Util_constructQueue(&appMsg);

CC2592_Enable();
.
.
.
.
.
}

and about the schematic I have to ask my director.

Thanks.

At least providing a scope / logic trace of the signal will help.

I see one issue in the code at least and that is keyPins/keyPinsCfg only being valid inside HGM_io_init (automatic local variables)

When the pin driver wants to use the PIN_State keyPins at a later time it will overwrite some random memory where keyPins where located which might even crash your program.

Also, you shouldn't use IOCPortConfigureSet but rather include them in the table given to PIN_open (as outputs) and then run PINCC26XX_setMux to route the pin to the RFCore GPO ports.

Regards,
Svend

Hi Svend,
I check the FW code first.
Thanks

Hi Vincent,

Could you post a schematic of your design?

Cheers,
Fredrik

Hi Fredrik,
About the schematic I still wait for my director.
and I just follow the Svend advice modify the FW like below
#include <ti/drivers/pin/PINCC26XX.h>

#define Board_HGM_PIN IOID_12
#define Board_LNA_PIN IOID_13
#define Board_PA_PIN IOID_14

PIN_Handle CC2592_Handle;
PIN_State keyPins;
PIN_Config keyPinsCfg[] =
{
Board_HGM_PIN | PIN_GPIO_OUTPUT_EN | PIN_GPIO_HIGH | PIN_PUSHPULL,
Board_LNA_PIN | PIN_GPIO_OUTPUT_EN | PIN_GPIO_HIGH | PIN_PUSHPULL,
Board_PA_PIN | PIN_GPIO_OUTPUT_EN | PIN_GPIO_HIGH | PIN_PUSHPULL,
PIN_TERMINATE
};

void HGM_io_init(void)
{
CC2592_Handle = PIN_open(&keyPins, keyPinsCfg);
PINCC26XX_setMux(CC2592_Handle, Board_LNA_PIN,IOC_PORT_RFC_GPO0);
PINCC26XX_setMux(CC2592_Handle, Board_PA_PIN, IOC_PORT_RFC_GPO1);
}

void CC2592_Enable(void)
{
HGM_io_init();
}

and I go out for the distance test. The CC2650 does SimpleBLEBroadcaster and Iphone does central.
the result of the distance is more then 800M.
So the CC2592 works full power now right?

Thanks

Hi Fredrik,

Thank you for the explanation. I have added the IOPortConfigureSet lines for PAEN and EN to my code as Vincent did, but using DIO_0 and DIO_1 on the CC2640. I tied HGM to 3.3V HIGH with a wire so it would always be high gain. The SimpleBLEPeripheral code compiles in IAR Workbench, and downloads onto the device with no errors.

Here is a code fragment, from main.c in the SimpleBLEPeripheral App code:
// Map RFC_GPO1 to DIO_01 (PAEN)
IOCPortConfigureSet(IOID_1, IOC_PORT_RFC_GPO1,IOC_IOMODE_NORMAL);
// Map RFC_GPO0 to DIO_00 (EN)
IOCPortConfigureSet(IOID_0, IOC_PORT_RFC_GPO0,IOC_IOMODE_NORMAL);

/* Initialize ICall module */
ICall_init();


However, I am still not seeing the SimpleBLEPeripheral show up as a bluetooth device.

There are three possible things I think might be the problem:
- does HGM have to float during TX, so I can't tie it to HIGH?
- does it have to be DIO7 and DIO13, as in your example, for this to work?
- do I have to call HCI_EXT_ExtendRfRangeCmd() for the code to work now? Maybe the code was updated since you answered the question in March 2015?

Please let me know what you think!

Hi Yoo,

Have you verified the RF output by measuring with a spectrum analyzer? Have you measured the CC2590 control signals with an oscilloscope? Do you know if your crystal frequency is correct?

Yoo Hsiu Yeh said:

- does HGM have to float during TX, so I can't tie it to HIGH?

No, HGM can be tied high during TX (as stated in the datasheet)

Yoo Hsiu Yeh said:

- does it have to be DIO7 and DIO13, as in your example, for this to work?

No, any DIO can be used, but make sure you are setting up the correct pins for PA- and LNA- enable

Yoo Hsiu Yeh said:

- do I have to call HCI_EXT_ExtendRfRangeCmd() for the code to work now? Maybe the code was updated since you answered the question in March 2015?

No, that is not required

Cheers,
Fredrik

Hi Fredrik,
It looks like there are no control signals coming out (only noise on PAEN and EN), and the spectrum analyzer doesn't pick up any signal around 2.4GHz. The crystal components are the same as those in the reference design, and the low-frequency crystal is oscillating; haven't been able to measure the 24MHz crystal.

I'm thinking it's a 95% chance that the problem is something in the firmware modification I tried to make, but there's still the 5% chance that the board itself isn't working. I tried to route the gain amplifier with the correct trace widths and lengths for the inductances that I reverse-engineered from the layout (the TILN inductances for the CC2541-CC2590 reference design aren't given). Would an inductance that was too large or too small cause the gain amplifier to not work?

thanks,
Yoo-Yoo

I found the error, and actually it was a wrong board.h file error:
I am using the 4mmx4mm chip package, and the project by default expects the pinouts of the 7mmx7mm package. I changed the settings so the compiler looked in the CC2650EM-4XS folder for the Board.h file instead, rebuilt and loaded the code, and now it works as expected.

thanks!

Hi Yoo,

I am glad to hear that you resolved the issue!

Cheers,
Fredrik