CC1312R: 5KBPS OAD function and high packet loss rate when issuing commands

Hi, 

When you use a 5kbps phy, the transmission times of packets over the air are quite high. This causes more collisions especially in a network of many nodes. 

You saw significant improvements when you used the 50kbps phy because, the transmission time is 10 times lesser. Makes it less susceptible to collisions. 

If you are using Frequency hopping, you can test by increasing the dwell times and intervals.

The join times are also typically slower in 5kbps phy because of the low data rates.

The SysCtrlSystemReset is a driverlib call that is pretty much a register write to the AON_PMCTL register and ends in a while(1); when you say it fails, what do you observe?

faker wang said:

SysCtrlSystemReset(); Reset function, but sometimes reset may fail.

Regards,

Sid

Hi sid:
1. After calling the SysCtrlSystemReset() function, I found that the uart of the sensor device no longer outputs logs and the LED light that was started did not flash normally (the default LED light would flash three times after the sensor was started, and I was in Sensor_init (_macTaskId); Output some startup logs near the function),
2. I have observed on the forum that someone is using the HAL_SYSTEM-RESET() function for resetting, and it has never failed. Can you tell me what h file this function should introduce?
Regards

Hi sid:
I understand it this way:
1.5kbps is suitable for scenarios with fewer long-distance devices and low requirements for data delivery rate
2.50kbps is suitable for scenarios with a large number of short distance devices and high data delivery rate requirements
May I ask if the above understanding is possible?
So, what is the approximate difference in communication distance and power consumption between 5K bps and 50K bps?
Can you provide me with a test report for 5K and 50K bps? I will carefully compare and choose an option that is suitable for our application scenario

Regards

faker wang said:

. I have observed on the forum that someone is using the HAL_SYSTEM-RESET() function for resetting, and it has never failed. Can you tell me what h file this function should introduce?

Hi,

Please can you share this thread. Because I found a define in mt_sys.c found in SDK\source\ti\ti154stack\apps\coprocessor\mt\mt_sys.c

which is simply redefining the SysCtrlSystemReset()

/*! Reset by using DriverLib supplied function */
#define HAL_SYSTEM_RESET() SysCtrlSystemReset()

Regards,

Sid

Hi sid；

The following is the original post address, but it is provided by the e2echine forum and may require translation to read:

https://e2echina.ti.com/support/wireless-connectivity/sub-1-ghz/f/sub-1-ghz-forum/800134/cc1310-cc1310-sysctrlsystemreset/2938261?tisearch=e2e-sitesearch&keymatch=SysCtrlSystemReset#2938261

I will post the translation as follows:
In CC1310, after restarting using SysCtrlSystemReset, the indicator light did not light up. To avoid HIB mode, when the TCK cable is directly connected to the VDD power supply, the indicator light does not light up. Attempting multiple methods failed to restart successfully.
Please ask experts to help analyze it. The circuit diagram and components are designed based on the official website.
This may be caused by multiple factors, and the following are some methods to troubleshoot and solve such problems:
Attempt to print log information before and after restarting to confirm that SysCtrlSystemReset did indeed cause the system to restart.
Ensure that the GPIO pin used for the indicator light is correctly configured after restarting. Sometimes, after a system reset, the status of the pins may be reset, and it may be necessary to initialize and configure these pins.
Try replacing SysCtrlSystemReset with HAL_SYSTEM-RESET(), which is equivalent to a hardware reset. If you can reset the hardware on the board, you can also use SysCtrlSystemReset
If the above software methods cannot solve the problem, the possibility of hardware failure cannot be ruled out. Check whether the CC1310 chip and related circuits have physical damage or poor contact.
Additionally, if this issue is related to stopping at startup, please refer to the following post. If there is no JTAG connection and external power supply, SysCtrlSystemReset() should work properly.
https://e2e.ti.com/support/wireless-connectivity/bluetooth/f/538/t/798229

May I ask if my above conjecture is correct?
1.We found during testing that the packet loss rate is relatively high when issuing commands at 5kbps, but the packet loss rate at 50kbps is already relatively low. What is the difference between 50kbps and 5kbps? In our scenario, a collector will interface with a large number of sensors (perhaps 100), so what is the difference in power consumption and communication distance between these two BPSs?
During testing, we found that 5kbps was difficult to meet our requirements for accessing 100 nodes and conducting instant messaging (such as OAD functionality)

2. I found the HAL_SYSTEM-RESET() function definition in the following path
C: \ ti \ simplink_cc13xx_cc26xx_sdk_7_10:02:23 \ source \ ti \ ti154stack \ hal \ platform \ hal_mcu. h

Regards，

faker

Hi ,sid :

Have you found any problems?

I conducted another test and found that restarting SysCtrlSystemReset() in the appTaskFxn task of the main function is normal.

But resetting to BIM after a successful load will fail, but when I manually disconnect the power and power on again, I can find that the sensor has been loaded with the new firmware. What is the reason for this? Looking forward to your reply

I tested it without connecting to the downloader, and I attempted to add Task_sleep (500) on SysCtrlSystemReset() after successful loading; Unable to restart successfully even with a delay of 500ms

Regards，

faker

Hi sid:

https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/623362/rtos-cc2640r2f-reboot-with-sysctrlsystemreset

In the following post, it is also mentioned to use the HAL_SYSTEM-RESET() function instead of the original reset function

All the HAL_SYSTEM_RESET() functions seem to be related to CC1310.

Please can you re-explain this.

faker wang said:

I tested it without connecting to the downloader, and I attempted to add Task_sleep (500) on SysCtrlSystemReset() after successful loading; Unable to restart successfully even with a delay of 500ms

Hi:

What I mean is that when the SysCtrlSystemReset() function fails to restart, I don't have a link to JTAG
However, during my testing today, I added a delay of about 1 second before the SysCtrlSystemReset() function and it can be reset normally. It seems that I still need to test multiple times to draw a conclusion。

What troubles me now is the issue of communication distance. I tested it in the environment of an underground garage
1. The communication distance of 5kbps can reach about 400 meters
2. The communication distance of 50kbps can only reach about 100 meters
Is this communication distance normal? Is there a way to optimize it?

Regards，

faker

Hi faker,

The range estimator provides an estimate for the range of different Phys and the second page of the excel workbook provides a Range Debug Check list. 

Please go through it for range concerns and tips.

https://www.ti.com/tool/RF-RANGE-ESTIMATOR

There is also the app note linked in the rf range estimator that could be useful in this case. 

https://www.ti.com/lit/an/swra479a/swra479a.pdf

Regards,
Sid

Hi sid:
Thank you for your reply. We have resolved the communication distance issue, but unfortunately, I tried to delay by 1 second before SysCtrlSystemReset() after the load was successful. However, after multiple tests, a restart failure still occurred. Can you help me find the reason for the failure?

Regards，

faker

Hi sid:
Thank you for your reply. I will get back to you with the results after conducting a large number of tests

Regards，

faker

Hi sid:

AON_PMCTL_RESETCTL_SYSRESET_BITN)=1;

There will still be situations where the restart fails. Can you help me find a solution to this restart problem again?

Regards，

faker

Hi faker,

In a simple single thread application, this seems to work fine. Are you sure that the register write is actually happening and then reset is not happening after the register write?

Regards,
Sid