CC1310: The wmbus timer stops working.

Hi team 

This is the emial customer send to me：

Hi Alex,

Here is the feed-back:

I have read through the message. It is quite odd that you have some devices that are working (‘normal devices’) and not working (‘unusual devices').

I believe you run the same code base on all devices?

1. Therefore, I would firstly advice to check the HW setup of each device. Perhaps the shutdown pin is in a different state between the devices? This pin can make the device go into sleep/shutdown mode which affects the device runtime.

If the shutdown pin is not the cause of the issue, I think that monitoring the RTC implementation may not verify if the device stops working or not. Unless you have more information to believe that the RTC is the cause.

2. Can you check whether the ‘stack task’ that is initiated by the main function is still running or not?

Cheers,

Marie H

Thank you for your help. I have already replied to my client with the message

Hi team:

The Customer said that：

Running debug shows that everything is working correctly. And I see here that it's OK to test the routines of wmbus alone. But I'm going to create a new task (lower priority than the wmbus task) and add some analogue serial debug to the problem, and I call HwiP_disable in my analogue serial debug. Feel like frequent switching interrupts affect the task running logic of wmbus? 

Hi team:

But when I turn off the interrupt, the scheduler won't work until I turn it on. So when I close the interrupt again, if there is an action on the wmbus task, it will be occupied by my own task until I release it. I'm not sure if this is the cause of the abnormality. Because from the comparison of my test results, the difference between the two programs is whether there is an action to close the interrupt.

Best Regards,

Alex

Hi Alex,

Can you give the specific code you use to "turn off" and "turn on the interrupt"?

I would only recommend to enable/disable it.

Cheers,

Marie H

Hi team:

This is a screenshot of my client program

Best regards

Alex

Hi Alex,

I see. Using HWI_disable while the WMBUS stack is running concurrently is a bad idea.

Is the application sharing this PIN (debugPinHandle) with the stack? If not, could you change the implementation e.g. to use a gate mutex?

Cheers,

Marie H

Hi team：

Thank you for your help

Best regards

Alex

Hi team：

There is no sharing, but I tested it with my routine and it was fine until a new task was opened and this debug was added. And then I shut down debug and then I'm going to test it. Then I put some of my application code into the test, and I found that there was another problem. But my application code doesn't turn off the interrupt. So, I've seen some of the APIs have the action of a switch interrupt, and if the switch interrupt affects the operation of the wmbus task, my other task called these APIs and caused the wmbus exception. I think that's a problem. That is, I have to tell if the wmbus task is running while another task is running. 

Best regards

Alex

Hi Alex,

What priority did you give your new task? Higher or lower than the existing tasks?

Cheers,

Marie

In total, two tasks, one with wmbus priority of 3 and the other with priority of 2