CC1310: BATMON + RF TX possible problem

Are you disabling the AON_BATMON as part of your measurements?

The BATMON should be left on as it is used internally by the Flash. If disabled, the flash will draw more current. If you're using TI-RTOS, then it's also used inside the power manager driver.

No I don't disable it.

I just used following API from aon_batmon.h:

AONBatMonNewBatteryMeasureReady
AONBatMonNewTempMeasureReady
AONBatMonBatteryVoltageGet
AONBatMonTemperatureGetDegC

No I don't disable the BATMON.

I just used the following APIs:

AONBatMonTemperatureGetDegC()
AONBatMonBatteryVoltageGet()
AONBatMonNewBatteryMeasureReady()
AONBatMonNewTempMeasureReady()

As Niklas points out the chip is using the BATMON to monitor the voltage.

Why do you want to monitor the voltage in your software?

Could you send us a minimal project that show the high CRC rate so we can test it here?

TER said:

As Niklas points out the chip is using the BATMON to monitor the voltage.

Could you be more specific? Is the RF part of the chip using it?

TER said:

Why do you want to monitor the voltage in your software?

As I said I want to check the battery level.

TER said:

Could you send us a minimal project that show the high CRC rate so we can test it here?

When I have time I will do that.

It's mainly the CPU part that uses the information and it's required for correct operation of the flash.

But why do you want to monitor the battery voltage (or in other words what do you want to do with the information?)

We are using a type of battery which near the end of life it has a lot of voltage drop, in particular during load(current consumption).It could go from 3.6(no load) to below 2.0V(it depends on how long the load lasts). If the voltage went below 2.0V the software would shut down any operation.

In the past I've done the BAT monitoring on CC1110 during TX with no problem using ADC.

The CC1310 has this wonderful BATMON but I cannot use it all the time.

How does the CC1310 behave if the voltage goes below 1.8V during TX? Does it reset? Does it have a failsafe mechanism?

Thank you for the use case.

If you manage to make a minimum TI-RTOS based project that show the faulty behavior we can take a look at it here.

CC1310 has a BOD that create a reset when the voltage is below 1.8 V.

I've created a project which shows the problem. It is based on rfEasyLinkTx sample project.

I've used following RF settings:

- EasyLink_Phy_50kbps2gfsk

- 915 Mhz

- 12dBm TX power

- no address

- PN9 whittening

I chose to use tx async mode. I've loaded the firmware into CC13xx-7XD-7793.  For receiving, I used the same ref board with smart rf studio.

Results:

- TX board @ 3.8V : 44%-51% packet error(out of 100)

- TX board @ 3.2V : 0% pkt error

- TX board @ 3.8V(async deactivated) : 0% pkt error

Project files:

[[View:/cfs-file/__key/communityserver-discussions-components-files/156/rfEasyLinkTx_5F00_CC1310DK_5F00_7XD_5F00_TI_5F00_CC1310F128.zip:1230:0]]

If you have any questions let me know.

Regards,

Milorad

Thank you. I have forwarded this request to the engineer that wrote the easylink examples and he will look at it later this week.

Milorad,

I tried to replicate this issue with the project you attached on a CC1310 LaunchPad using an external power supply. With the VCC to the CC1310 set to 3.8v I could not see any errors on SmartRF studio, I could only see errors if I increased the VCC well above the operating condition of the CC1310.

What HW are you using? Thank you for sending the project, we are now aligned on SW,  it would be good if we can also align on HW to isolate the issue. If you are using your own HW, would it be possible to test again on a CC1310 LaunchPad?

Regards, TC.

No, we are not using the lauchpad.

Our HW guy modified the EM board to use external power.

See pictures:

[]

[]

As far as I know I used  voltage no more than 3.8V.

Can you tell us if there any problems connecting external power in that way(like in photos)?

Thank you and regards,

Milorad

The power connection looks correct. I would recommend getting a Launchpad at one point, it requires less modifications ;)

What was the voltage when you started to have packet errors?

I saw the errors starting at >4v. This is outside of the operating range of the device and I would not recommend trying it.

Have you tried the test across multiple devices? If you have only tested on 1 device is it possible that it could have been damaged while modifying the board? Maybe damaged by ESD?

I did some testing and I see that if I use an EM as Tx I get 30-50 % packet errors if VDDS > 3.7 V but if I use a launchpad as Tx I never get CRC errors for VDDS > 3.7 V. I have to admit that I don't know why this is the case. The EM and the launchpad are for most practical considerations equal. As a double test I used the same antenna attached to the EM as the Launchpad uses.

The Tx side was running the software you attached

Could you follow up on this problem?
Our application boards are based on the EM design. I already implemented a workaround in the firmware, but we want to eliminate any future issues with the hardware.

Thank you and regards,
Milorad

Hi TER,

Any updates on the reason for this issue?
Our customer's application has same problem with CC1310.

They get CRC error with higher voltages,
>more than 3.4V: 100% CRC Error
>less than 2.7V: no CRC Error

Best Regards
Kummi

I haven't looked more into this since LPs are the platform we provide customers.

Kummi: Have your customer tested with a LP as Tx or just a custom board as Tx? If the later, could they do a quick test with a LP?