• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 53 subscribers
  • Views 806 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.

CC1352P: In-application / Runtime programming of CCFG area - possibility/example

Chander G
Intellectual 2420 points
Part Number: CC1352P


Hi,

My customer is trying to calibrate the XOSC. They get the SET_CCFG_MODE_CONF_XOSC_CAPARRAY_DELTA value on UART from a reference unit. Now they want to program this value in the CCFG area - DEFAULT_CCFG_MODE_CONF register @ 0x50003FB4 address. 

Is it possible to alter the CCFG area at the run time? If yes could you pls provide example. The nvs driver example doesn't seem to be capable of writing into CCFG area.

Regards,

Chander

  • 0
    TI__Intellectual 2180 points

    Hi Chander,

    I'll work to find an appropriate expert to refer to too, but this may take a few days as availability is currently limited.

    Briefly looking into this, I don't believe the CCFG sector of flash is write-protected by default, so it should be possible to use the NVS driver if it is a valid flash address. The CCFG is stored in the last sector of flash (0x56000), but I would have to dig deeper to see the offset of where DEFAULT_CCFG_MODE_CONF is stored. I would caution against modifying this sector at run-time though, because if you need to update this sector, you will need to perform a flash sector erase-write operatio. This could brick the device if power-loss occurs during the CCFG update. 

    However, it appears your goal is to modify the register at run-time, in which case you would directly need to write to the appropriate register instead of an internal flash address.I think all of the CCFG domain registers are read-only, so I am not sure if what you are trying to accomplish is possible.

    Regards,
    Michael

  • 0
    TI__Guru**** 317180 points

    I would avoid doing that. To be able to program the CCFG area without restrictions you have to erase the last page before you can reflash the page. If you are forced to reset in between these operations you will most likely have bricked your chip. 

    But it's not clear what they are trying to do. The cap array is something that is typically is found in production testing. 

    I could not find DEFAULT_CCFG_MODE_CONF in the TRM? 

  • 0 in reply to TER
    TI__Intellectual 2420 points

    Michael & TER,

    Thanks for your replies. On digging further, I found that the following function can be used to modify the values of XOSC Cap Array on the run time.

    void OSC_AdjustXoscHfCapArray ( int32_t  capArrDelta )

    So the customer can store the value in a NVS area instead of CCFG during production calibration. In the end application, the customer can use the above function to override the default values loaded by the bootloader.

    From your experience, do you see whether is approach will work fine?

    Regards,

    Chander 

     

  • 0 in reply to Chander G
    TI__Guru**** 317180 points

    Customers uses this approach, storing a value somewhere in the flash and then using  OSC_AdjustXoscHfCapArray to apply this value. 

    But: For CC1352P it's recommended to use external load caps meaning that this function will have limited effect. But if you know the frequency offset you can adjust for this in CMD_FS.