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: SDK 7.40.00.64 update

Part Number: CC2340R5
Other Parts Discussed in Thread: SYSCONFIG

Hi,

 

I was just quickly playing with the new SDK for the CC2340R5. I see that the LRF_txPowerTableMsk250Kbps and LRF_configMsk250Kbps arrays, which define the TX output power and radio settings in the radio module are gone for this board. They are however included in the CC27XX folder.

 

What should we be using then to choose the TX power? Should we use the ones defined for CC27XX or do we need to generate something on our own?

I saw in the SDK examples you used some generated header.

Note: We are using a proprietary wireless protocol.

 

 

__________________________________

 

Additionally, I saw an update for the battery monitor in the errata:

 

 

 

as we are using the temperature diode for temperature, we shouldn't be affected by this bug as far as I know?

 

__________________________________

 

The RCL_AdcNoise.c file (simplelink_lowpower_f3_sdk_7_40_00_64\source\ti\drivers\rcl\wrappers) is using an incorrect path to the RCL settings file and causing us a build error. Did any other customer report this or are we using it in a wrong way? We use this file to generate radio noise used as entropy for the RNG.

#ifdef DeviceFamily_CC27XX

#include <ti/boards/cc27xx/rcl_settings_adc_noise.h>

#else

#include <ti/boards/cc23x0/rcl_settings_adc_noise.h>

#endif

 

We have been using the function RCL_AdcNoise_get_samples_blocking

 

__________________________________

 

Note: we are currently using SDK version 7.10.00.35


BR,

Matija

  • Hi Matija,

    1. LRF_txPowerTableMsk250Kbps and LRF_configMsk250Kbps appear to have been changed to LRF_txPowerTable and LRF_config_msk_250_kbps* from what I can determine from the ti_radio_config.c/h of the SysConfig output.  You can evaluate a default CC23XX PropRF example to confirm, however I do not recommend using CC27XX references.  What matters is that the correct resources are called during RCL_open.
    2. Here is a link to the Errata in question.  This could only affect a small set of devices which explains why you have not observed it before.  It would be prudent to upgrade to the SDK which applies the fix automatically or at least implement the solution from simplelink_lowpower_f3_sdk_7_40_00_64\source\ti\drivers\batterymonitor\BatMonSupportLPF3.c into your existing SDK.
    3. Thank you for catching this bug, I've reported it to the TI Driver Software Development Team so that this can be corrected to "cc23x0r5" at the very least.

    Regards,
    Ryan

  • Hi Ryan,

    thank you for the updates! Can you let me know when is the update for point 3. planned after checking in with the team?

    BR,
    Matija

  • Hi Matija,

    The best course of action is still being determined given upcoming development plans.  Can you please explain whether your workaround will not be sustainable for the indeterminate future?

    Regards,
    Ryan

  • Hi, as we are using this directly from the SDK,

    our only workaround can actually be to directly change SDK (unpreferable) or copy the whole file to our project directly (not easy because of all the dependencies it has)


    None of the options are viable for us, best to wait with the SDK update in that case. That's why my question was oriented to actually get a certain timeframe for the SDK update.

    BR,

    Matija

  • Thanks for the additional feedback.  I can forward your response to the Software Development Team for further consideration.  I do not believe there is time to have this resolved in the upcoming v8.10 F3 SDK.

    Regards,
    Ryan