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

CC2340R5: CC2340R5 48Mhz Clock Accuracy

Robert Weekly
Prodigy 60 points
Part Number: CC2340R5

Tool/software:

I am having a lot of problems with timing accuracy using the CC2340R5 and BLE Stack.

I have managed to configured DIO19 to output the 48Mhz / 8 = 6Mhz to try and validate the underlying the clock frequency.

This seems to vary from 6.0007 Mhz to 5.952 Mhz. I am really trying to setup this Application to perform some realtime processing, hence I am looking for accurate time domain.

A few questions on this device which I can't work out from the Datasheet.

1) Does the ARM core actually run of the HFEXT 48Mhz crystal - or does it always using the less accurate internal RC Oscillator?

2) I've tried utilising the HFXT Cap Array adjustments - but no real change with those. The reference design from TI shows not to use load capacitors on the crystal itself, maybe I should just try that.

Any support on this would be really helpful.

For anyone else trying to output the clock here is the code snippet I've used. (Placed after Board_Init() )

/* Start of 48Mhz CLK Debugging */
// drive output low first
GPIO_setConfig(19, GPIO_CFG_OUTPUT | GPIO_CFG_OUT_LOW );

// Conigure the IOC.IOC19 PORTCFG MMR to seelct DTB
HWREG(IOC_BASE + IOC_O_IOC19 ) &= ~IOC_IOC19_PORTCFG_M ;
HWREG(IOC_BASE + IOC_O_IOC19 ) |= IOC_IOC19_PORTCFG_DTB ;

//
HWREG(IOC_BASE + IOC_O_DTBCFG) &= ~IOC_DTBCFG_ULLSEL_M ;
HWREG(IOC_BASE + IOC_O_DTBCFG) |= 0x1 << IOC_DTBCFG_ULLSEL_S ; // 0x1 to route CLKD to DTB0

// Enable IOC.DTBOE.EN0
HWREG(IOC_BASE + IOC_O_DTBOE) &= ~IOC_DTBOE_EN0_M ;
HWREG(IOC_BASE + IOC_O_DTBOE) |= IOC_DTBOE_EN0_EN ;

// Seelct which clock (CKMD) to output on DTB0 (DTB[0])
HWREG(CKMD_BASE + CKMD_O_DTBCTL) &= ~CKMD_DTBCTL_CLKSEL_M ;
HWREG(CKMD_BASE + CKMD_O_DTBCTL ) |= (clockSrc) << CKMD_DTBCTL_CLKSEL_S ;

// enable DTB Output
HWREG(CKMD_BASE + CKMD_O_DTBCTL) &= ~CKMD_DTBCTL_EN_M ;
HWREG(CKMD_BASE + CKMD_O_DTBCTL ) |= CKMD_DTBCTL_EN;
/* End of CLK Debugging */

  • 0
    TI__Guru**** 171064 points

    Hi,

    Thanks for the inquiry. I think the most comprehensive resource to help you with the overarching task of evaluating the performance of the crystal and get additional information about the clock subsystem is the application note Crystal Oscillator and Crystal Selection for the CC13xx, CC26xx, and CC23xx Family of Wireless MCUs (SWRA495)

    1) the core MCU indeed operates directly from the external HFOSC, which is fed by the external crystal if present.

    2) considerations about the load capacitance can be found in section 3.3 of the application note mentioned above.

    Hope this helps,

    Rafael

  • 0 in reply to desouza
    Prodigy 60 points

    Thanks for the extra reference material sent on this.

    I have now managed to get the HFOSC clock output aligned to 6Mhx ( 48Mhz / 8 ) on the DTB0 output pin. To achieve this I swapped crystal to that as detailed in SWRA495 and also had to modify the config for the internal load capacitors to 0x21 values.

    I will back track later on our original crystal choice.

    I am still wary of how accurate this device is clocking. Now have a hardware interrupt on Timer2 firing which should be 1ms, minimal code inside - literally just 
    GPIO Toggle, but this wanders several microseconds. I would expect HW interrupt latency to be consistent, and highest priority compare to my RTOS tasks.

    Puzzling. Although first time battling with FreeRTOS and the new TI BLE Stack F3. Umm, could this be causes by Stack Hardware interrupts which are active for the Radio? There is little detailed information about what is actually going on within the STACK.

  • 0 in reply to Robert Weekly
    TI__Guru**** 171064 points

    Hi,

    This seems to be wandering towards a SW or RTOS issue indeed. In conversations with the SW team, it was suggested that you use the "empty" example project of the SDK to implement your timer interrupt - this example will have the bare minimum functionality activated and therefore isolate the behaviour you are seeing to the timer/interrupt itself. Let us know the outcome of this experiment.

    If there is a protocol stack or other functions running at the tune of the RTOS system tick, the use of a second timer or the piling of timer interrupts can potentially add some skew.

    Regards,

    Rafael