AWR2243: Temperature Monitor

Hi,

Can you provide more information as follows

1) Which version of the SDK are you using. 

2) Are you using TI EVM or a custom board.

3) What do you mean by RF operation became abnormal. Was any error reported. If yes, can you share the error code.

4) Are any other monitors being used. If yes which ones.

5) Have you configured the Temperature monitor. Can you share the configuration used.

6) What is your programming sequence. Is it as per chapter 6 of the Interface Control document or otherwise. If any changes, please let us know the reasoning behind the change.

Thanks,

Pradipta.

Hi,

1) We are using SDK2.2.2.1.

2) We are using our own board.

3）We configured RF to automatically send frames. We turn on the temperature monitoring, and the frame will stop sending after about 5 seconds; if we turn it off, there will be no problem. Host had not received any error report. In addition, our board and program are validated, and all functions are working fine as long as the temperature monitoring is not turned on.

4）No，just this one.

5）Firtst, we used MMWL_rlRfAnaMonConfig to enable temperature monitor.

And then, we used rlRfTempMonConfig to Config the parameters:

tempMonReportMode=2;
tempMonAnaTempThreshMin=-40;
tempMonAnaTempThreshMax=135;
tempMonDigTempThreshMin=-40;
tempMonDigTempThreshMax=135;
tempMonTempDiffThresh=30;

6）Yeah，we did it according to the programming sequence in Chapter 6.

Hi，

Thanks, we got it.

Another question: we want to monitor TX0 && TX1 && TX2 power, The steps are：

1) Invoke MMWL_rlRfAnaMonConfig:

int MMWL_rlRfAnaMonConfig(unsigned char deviceMap)
{
  int32_t retVal; 
  rlMonAnaEnables_t rlAnaMonCnfgArgs = { 0 };

  /* read rlAnaMonCnfgArgs from config file */
  rlAnaMonCnfgArgs.enMask = (1 << 4) | (1 << 5) | (1 << 6);
  rlAnaMonCnfgArgs.ldoVmonScEn = 0;

  printf("Calling rlRfAnaMonConfig with \nenMask[0x%x]\nldoVmonScEn[0x%x] \n\n", \
          rlAnaMonCnfgArgs.enMask, rlAnaMonCnfgArgs.ldoVmonScEn);

  /* Analog monitoring configuration */
  retVal = rlRfAnaMonConfig(deviceMap, &rlAnaMonCnfgArgs); /* 模拟监控配置 */
  return retVal;
}

2) Invoke MMMWL_setCalMonConfig:

int MMMWL_setCalMonConfig(unsigned char deviceMap)
{
  int retVal; 
  rlRfCalMonTimeUntConf_t rlCalMonTimeUntArgs = { 0 }; 

  /* set monitoring Unit etc. */
  rlCalMonTimeUntArgs.calibMonTimeUnit = 3;
  rlCalMonTimeUntArgs.devId = 0; 
 rlCalMonTimeUntArgs.numOfCascadeDev = 1; 
  rlCalMonTimeUntArgs.monitoringMode = 1; 
  rlCalMonTimeUntArgs.reserved = CAL_MON_RESERVED;

  printf("Device map %u : Calling rlRfSetCalMonTimeUnitConfig with \ncalibMonTimeUnit[%d]\ndevId[%d]\nnumOfCascadeDev[%d]\nmonitoringMode[%d]            \n\n",deviceMap, rlCalMonTimeUntArgs.calibMonTimeUnit, rlCalMonTimeUntArgs.devId, rlCalMonTimeUntArgs.numOfCascadeDev,               rlCalMonTimeUntArgs.monitoringMode);

  retVal = rlRfSetCalMonTimeUnitConfig(deviceMap, &rlCalMonTimeUntArgs);

  if (retVal != 0)
  {
     printf("Device map %u : rlRfSetCalMonTimeUnitConfig [Error %d]\n\n", deviceMap, retVal);
     return -1;
  }

return 0;

}

3) Invoke MMWL_setRfTxPowMonConfig:

int MMWL_setRfTxPowMonConfig(unsigned char deviceMap)
{
  int32_t retVal;

  rlTxPowMonConf_t rlTxPowerMonCnfgArgs = { 0 };

  rlTxPowerMonCnfgArgs.profileIndx = 0;
  rlTxPowerMonCnfgArgs.rfFreqBitMask = 2;
  rlTxPowerMonCnfgArgs.reportMode = 0;
  rlTxPowerMonCnfgArgs.txPowAbsErrThresh = 20;
  rlTxPowerMonCnfgArgs.txPowFlatnessErrThresh = 20;

  rlAllTxPowMonConf_t data = { &rlTxPowerMonCnfgArgs, &rlTxPowerMonCnfgArgs, &rlTxPowerMonCnfgArgs };

  retVal = rlRfTxPowrMonConfig(deviceMap, &data);

  return retVal;
}

4) Invoke rlMonTypeTrigConfig:

   mmwl_bMonTypeTrigDone[0] = 0U;
   rlMonTypeTrigCfgs.monTrigTypeEn = 7;
   retVal = rlMonTypeTrigConfig(deviceMap, &rlMonTypeTrigCfgs);
   if(retVal != NO_ERROR){
   return MMWL_APP_FAILED_MonitoringConfig_C0;
 }

The serial port printing display shows that TX0, TX1, and TX2 only triggered one asynchronous event. which, like temperature monitoring, affected the normal transmission of frames. The frames stopped transmitting after about 5 seconds.

In this way, as long as the monitor is turned on, it will affect the normal transmission of chirp. Why is that?

Hi,

Can you try with the below combination.

1) In type trigger API do not trigger all the monitors by programming 0x07. Only enable the type to which your monitor corresponds to and check.

2) Change the monitoring mode to 0 and do not use the type trigger and check.

Let me know of the observations in both the cases.

Thanks,

Pradipta.

Hi,

1) monTrigTypeEn = 0x02, The serial port print is as follows：

In our program, calibMonTimeUnit = 3,  frame_period=65ms, total time is 195ms. 

2) Change the monitoring mode to 0,The serial port print is as follows：

We configured RF to automatically send frames. Like the serial port print ,the frame will stop sending after about 5 seconds.This is not correct.

It seems that we cannot open any monitoring, and once opened, it will affect chirp sending. 

This is very troubling for us. We don't know the reason and how to solve it.

Thanks.

Hi,

Let me check on this internally and get back to you by next week.

Thanks,

Pradipta.

Hi,

Ok, thank you very much. 

Hi,

reportMode set to 0, is suggested only for debug or during the application development phase not in the final version of the application. Set it either 1 or 2.

If you have enabled multiple type of monitors along with runTime calibration, then BSS needs to perform those Monitor and calibration and send the async-event report within given FTTI.

BSS has limited size of queue for storing the async-event. If application doesn't read these async-event within time so this queue gets overflow and BSS functionality is not guaranteed in that case (e.g. frame not generating). So set the monitor reportMode to either 1 or 2.

.

Let us know if that resolves your issue.

.

Regards,

Jitendra