CC2630: Issue running TIMAC stack on a new MCU

Do you change MODULE_CC26XX_7X7 define to MODULE_CC26XX_4X4 in compile option?

I changed MODULE_CC26XX_7x7 to MODULE_CC26XX_4X4D (the "D" is for the differential front end setup to match what's on my custom board).

I also tried defining the MODULE_CC26XX_4X4 symbol (without the "D"), and it has led to exactly the same result.

It appears that my chip is HW revision D (2.3), but the driver libraries I'm using are built for rev. 2.2 in the SDK I'm using (TIRTOS Simplelink 2.11).

Is this the issue?  What should I do?

I broke up the line

MB_ASSERT( (MB_CMDSTA_REG & 0xFF) == CMDSTA_DONE || (MB_CMDSTA_REG & 0xFF) == CMDSTA_SCH_ERR );

into two lines:

MB_ASSERT( (MB_CMDSTA_REG & 0xFF) == CMDSTA_SCH_ERR );
MB_ASSERT( (MB_CMDSTA_REG & 0xFF) == CMDSTA_DONE );

The error I'm seeing is that MB_CMDSTA_REG contains CMDSTA_SCH_ERR = 0x86 = SchedulingError

Hi Michael,

The MODULE_CC26XX_4X4 definition should ensure that the proper Board.h file is used.  Have you confirmed radio operation of this device using SMARTRFTM-STUDIO?  Did you have the same project previously operating with a CC2630 RGZ device?  The TI-RTOS version appears correct (2.11), make sure you are using IAR EWARM 7.40 as well.

Regards,
Ryan

Hi Ryan,

My coworker was able to confirm the radio operation via SmartRF Studio.

I will try IAR 7.40 later today, although I don't see how this can make any difference.  I'm currently running IAR 7.80.4.

The code runs fine on a 7x7 CC2630 RGZ MCU, but not on the 4x4 CC2630.  The only difference between the two MCUs that I can see, other than the size, is that the 7x7 MCU is rev C (2.2) and the 4x4 MCU is rev D (2.3).  Does this make any difference?

Running the code again a few times, I began seeing different failure paths. For example, when the ICall_createRemoteTasks() -> Task_restore() execution halts in the main application, the TIMAC stack seems to be stuck in the following call chain:

stack_main() -> macLowLevelInit() -> macSetupRfHal() -> halAssertHandler()

where macSetupRfHal() is stopping at the following code:

  /* get a RAT channel for each desired function */
  if ( (macRatChanA = RFHAL_AllocRatChan()) == RAT_CHAN_INVALID )
  {
    HAL_ASSERT( FALSE );   // <---This is where the error is trapped and the stack halts
  }

The difference between package builds are contained in the ti/boards/SRF06EB/CC2650EM_[7ID/4XS]/Board.[h/c] files, and these should only concern IO driver initialization.  I do not know why you would be experiencing RF initialization issues unless the board hardware was faulty.  MCU rev does not matter.  Are you able to operate Z-Stack or Proprietary RF firmware with this setup?

Regards,
Ryan 

My coworker was able to confirm with SmartRF Studio that the hardware works.  I don't have a way to test Z-Stack or Proprietary RF firmware.  My current concern is that the device trim settings we've been using for years in our FW with other devices (we've been using CC2630 7x7 chips and CC2650 chips) are somehow not applicable to the CC2630 4x4 chip.  I'm referring to the the settings found in the ccfg.c file:

//**************************************************
// Minimum voltage to use for alternative DCDC setting
//
// (28 + ALT_DCDC_VMIN)/16:
// 0: 1.75V 
// 1: 1.8125V 
// ...
// 14: 2.625V 
// 15: 2.6875V 
//**************************************************
#define SET_CCFG_MODE_CONF_1_ALT_DCDC_VMIN              0x8

//**************************************************
// Enable DC/DC dithering for alternative DCDC setting
//**************************************************
#define SET_CCFG_MODE_CONF_1_ALT_DCDC_DITHER_EN         0x0        // Disable
//#define SET_CCFG_MODE_CONF_1_ALT_DCDC_DITHER_EN       0x1        // Enable

//**************************************************
// Inductor peak current for alternative DCDC setting
// 0: Min 31mA 
// 4: Typical 47mA 
// 7: Max 59mA 
//**************************************************
#define SET_CCFG_MODE_CONF_1_ALT_DCDC_IPEAK             0x2

//**************************************************
// Signed delta value for IBIAS_INIT
//**************************************************
#define SET_CCFG_MODE_CONF_1_DELTA_IBIAS_INIT           0x0

//**************************************************
// Signed delta value for IBIAS_OFFSET
//**************************************************
#define SET_CCFG_MODE_CONF_1_DELTA_IBIAS_OFFSET         0x0

//**************************************************
// Unsigned value of maximum XOSC startup time in units of 100us
//**************************************************
#define SET_CCFG_MODE_CONF_1_XOSC_MAX_START             0x10

//**************************************************
// Disable flag for alternative DCDC setting
//**************************************************
#define SET_CCFG_SIZE_AND_DIS_FLAGS_DIS_ALT_DCDC_SETTING 0x0       // Alternate DCDC setting enabled
//#define SET_CCFG_SIZE_AND_DIS_FLAGS_DIS_ALT_DCDC_SETTING 0x1     // Alternate DCDC setting disabled

//**************************************************
// Disable flag for XOSC override functionality
//**************************************************
//#define SET_CCFG_SIZE_AND_DIS_FLAGS_DIS_XOSC_OVR      0x0        // Enable override
#define SET_CCFG_SIZE_AND_DIS_FLAGS_DIS_XOSC_OVR        0x1        // Disable override

//**************************************************
// Select DC/DC during recharge
//**************************************************
#define SET_CCFG_MODE_CONF_DCDC_RECHARGE                0x0        // Use the DC/DC during recharge in powerdown
// #define SET_CCFG_MODE_CONF_DCDC_RECHARGE             0x1        // Do not use the DC/DC during recharge in powerdown

//**************************************************
// Select DC/DC during active mode
//**************************************************
#define SET_CCFG_MODE_CONF_DCDC_ACTIVE                  0x0        // Use the DC/DC during active mode
// #define SET_CCFG_MODE_CONF_DCDC_ACTIVE               0x1        // Do not use the DC/DC during active mode

//**************************************************
// VDDR external load
//**************************************************
// #define SET_CCFG_MODE_CONF_VDDR_EXT_LOAD             0x0        // VDDR may be loaded externally (may not be supported)
#define SET_CCFG_MODE_CONF_VDDR_EXT_LOAD                0x1        // VDDR is not loaded externally

//**************************************************
// VDDS BOD level
// 
// Note that production devices meant for 
// 125 degrees C operation will have a VDDS_BOD 
// level of 2.0V trimmed in e-fuse, which means 
// that VDDS_BOD_LEVEL in CCFG will have no 
// function on these devices.
//**************************************************
// #define SET_CCFG_MODE_CONF_VDDS_BOD_LEVEL            0x0        // VDDS BOD level is 2.0V (necessary for 125 deg C, ext load mode, or for maximum PA output power on CC13xx)
#define SET_CCFG_MODE_CONF_VDDS_BOD_LEVEL               0x1        // VDDS BOD level is 1.8V (or 1.65V for external regulator mode)

//**************************************************
// SCLK LF option
//**************************************************
// #define SET_CCFG_MODE_CONF_SCLK_LF_OPTION            0x0        // Low frequency clock derived from High Frequency XOSC
// #define SET_CCFG_MODE_CONF_SCLK_LF_OPTION            0x1        // TBD: Digital input from AON (selects XOSC_LF as source and XOSC_LF_DIG_BYPASS=1)
#define SET_CCFG_MODE_CONF_SCLK_LF_OPTION               0x2        // Low frequency XOSC
// #define SET_CCFG_MODE_CONF_SCLK_LF_OPTION            0x3        // Low frequency RCOSC

//**************************************************
// RTC compensation
//**************************************************
// #define SET_CCFG_MODE_CONF_RTC_COMP                  0x0        // Apply RTC temperature compensation (may not be supported)
#define SET_CCFG_MODE_CONF_RTC_COMP                     0x1        // Don't apply temperature compensation to the RTC

//**************************************************
// XOSC frequency
//**************************************************
// #define SET_CCFG_MODE_CONF_XOSC_FREQ                 0x0        // MEMS, reserved
// #define SET_CCFG_MODE_CONF_XOSC_FREQ                 0x1        // BAW, reserved
// #define SET_CCFG_MODE_CONF_XOSC_FREQ                 0x2        // 48MHz (may not be supported)
#define SET_CCFG_MODE_CONF_XOSC_FREQ                    0x3        // 24MHz

//**************************************************
// Enable XOSC cap-array delta
//**************************************************
#define SET_CCFG_MODE_CONF_XOSC_CAP_MOD                 0x1      ///< Don't apply cap-array delta 


//**************************************************
// HF compensation
//**************************************************
// #define SET_CCFG_MODE_CONF_HF_COMP                   0x0        // Apply 48MHz compensation (may not be supported)
#define SET_CCFG_MODE_CONF_HF_COMP                      0x1        // Don't apply 48MHz frequency compensation 

//**************************************************
// Value of XOSC cap-array delta
//**************************************************
#define SET_CCFG_MODE_CONF_XOSC_CAPARRAY_DELTA        (0xFF)     ///< Signed 8-bit value, directly modifying trimmed XOSC cap-array value

//**************************************************
// Value of VDDR capacitance
//
// This should take into account capacitor tolerance 
// and voltage dependent capacitance variation.
//**************************************************
#define SET_CCFG_MODE_CONF_VDDR_CAP                     0x3A       // Unsigned 8-bit integer representing the min. decoupling capacitance on VDDR in units of 100nF

We're using a 3.3V MCU power supply, so the internal DC-DC is enabled.

Do any settings above look like they might be wrong for the CC2630 4x4 rev D?

Hi Michael,

There are no changes required to the CCFG file.  There still could be an issue with the hardware design that is not caught in SMARTRFTM-STUDIO, I recommend you compare your PC board with the CC2650EM-4XD-RD and consider submitting your design to SIMPLELINK-2-4GHZ-DESIGN-REVIEWS for further review.

Regards,
Ryan

I've submitted our hardware design for a review, but I just wanted to run one last thing on the software front by the TI experts on this forum.

My team ran the pinInterrupt example from the TIRTOS 2.11 SDK built in IAR 7.40.3.  We only slightly modified the pin assignments in the code to match our custom board pinout.  Essentially, the code looked like this:

int main(void)
{
    /* Call board init functions */
    Board_initGeneral();

    /* Open LED pins */
    ledPinHandle = PIN_open(&ledPinState, ledPinTable);
    if(!ledPinHandle) {
        System_abort("Error initializing board LED pins\n");
    }
/// Other code follows
}

And the PIN_open() function ended up erroring out.  The LED pin table had proper pin definitions with no duplicate entries and in the valid IO number range (we only changed the IO numbers to match our custom board).  Any idea what kind of hardware issue might have caused PIN_open() to fail?

Thanks,

Michael

Hey Michael,

PIN_open will fail if one of the ledPinTable entries is already being used by another peripheral or the pin cannot be accessed.  As this code is modified from an example I would not expect the former to be an issue.  The latter however is possible given the reduced number of IO pins on the 4x4 package.  Have you attempted to run this code with your 7x7 design?  Can you make step-by-step changes to identify which pin entry causes the problem?  Otherwise, the physical hardware states of the pins themselves should not affect the operation of PIN_open.

Regards,
Ryan

We haven't tried running this code on a 7x7 design.

The only change we made in this example was to the LED pin definitions to bring them into the acceptable range for the 4x4 package (and make sure they can be driven by the MCU on our custom board):

#define Board_LED1  IOID_0
#define Board_LED2  IOID_1
#define Board_LED3  IOID_3
#define Board_LED4  IOID_8

My question is more along the lines of what could possibly be the reason why our board can't run certain API functions like a GPIO port initialization or radio initialization.  For example, one of the HW design issues we had was not being able to place some of the MCU decoupling capacitors and DC/DC regulator components on the same side of the board as the MCU (due to board size limitations).  Could that possibly be the reason for failing to run PIN_open()?  Like, maybe PIN_open() enables a specific clock source to the GPIO port that causes the MCU to behave erratically because of the misplaced components?  Any hint as to what specific HW issue might be causing this behavior would be helpful!

Thanks,

Michael

The source for PIN_open can be checked in PINCC26XX.c from the TI-RTOS directory:

PIN_Handle PIN_open(PIN_State* pState, const PIN_Config aPinList[]) {
    uint_t i;
    bool bOk;
    uint32_t bmPort;
    PIN_Id pinId;

    // Ensure that only one client at a time can call PIN_open() or PIN_add()
    Semaphore_pend(Semaphore_handle(&PinSem), BIOS_WAIT_FOREVER);

    // Check whether all pins in aPinList are valid and available first
    for (i=0, bOk=true, bmPort=0; aPinList && (pinId=PIN_ID(aPinList[i]))!=PIN_TERMINATE; i++) {
        /* Unassigned pins is allowed, but cannot generate a bitmask. */
        if (pinId != PIN_UNASSIGNED) {
            if (pinId>=PIN_NumPins || PIN_HandleTable[pinId]) {
                bOk = false;
                break;
            } else {
                // Generate bitmask for port operations (always one port on CC26xx)
                bmPort |= (1<<pinId);
            }
        }
    }

    if (!bOk) {
        // Indicate that the pins were not allocatable
        pState = NULL;
    } else {
        // Setup state object
        pState->pCbFunc = NULL;
        pState->bmPort = 0;
        pState->userArg = 0;

        // Configure I/O pins according to aPinList
        for (i=0; aPinList && (pinId=PIN_ID(aPinList[i]))!=PIN_TERMINATE; i++) {
            if (pinId != PIN_UNASSIGNED) {
                PIN_HandleTable[pinId] = pState;
                pState->bmPort |= (1<<pinId);
                PIN_setConfig(pState, PIN_BM_ALL, aPinList[i]);
            }
        }
    }

    Semaphore_post(Semaphore_handle(&PinSem));
    return pState;
}

IO3 is also JTAG TDO, so if 4-wire JTAG is enabled then TDO operation will precede any other pin functionality.

Regards,
Ryan

We're using cJTAG, and we don't have connections from TDI/TDO to our debug probe.

Thanks for the update, I don't have any further suggestions.  Please let me know if/when you have more debug information to share.

Regards,
Ryan