TMS320F28033: "CPU write" data lost when "CPU write" and "CLA read" access to CPUtoCLARam area simultaneously

Hi Rayna,

The other e2e thread you have referred to talks about 'CLA to CPU Message RAM' while your query is about 'CPU to CLA Message RAM'. Please note that there are differences in the priority scheme of both the memories.

As shown in the TRM, in case of 'CPU to CLA Message RAM', CLA reads get higher priority over CPU writes. There is a high chance in your observations that CLA has started reading the uiDcdcVoltK3/4/5 variables before CPU has finished writing them. Can you please check if that is the case?

Regards,
Praveen

Hi Praveen,

Yeah, you're correct.  The RAM what I mentioned is difference with the other e2e link, however, don't you think the e2e reply could be changed to "the lower action is not ignored but stalled and access is given after higher action is done"?

"There is a high chance in your observations that CLA has started reading the uiDcdcVoltK3/4/5 variables before CPU has finished writing them."

I understand what you mean, and I also agree with condition you said. I also mentioned that in step2, the result could be acceptable if "CPU write" and "CLA read" access simultaneously.

Maybe the last message is not so clear to express my opinion. Thank you for your analysis, and I try to explain again in the below, if you have question, please let me know.

• The debug process is from step1 to step3, finally system will keep running in step3 condition. When the system keep running in step3 condition, the variables are still unchanged. 
• What we confused is that why the variables value is not changed as the value in dcdcCpu_isr loop, in other word, that why CPU don't keep to finish writing after CLA finish reading, when the code keeps running in "1024L<MdlCurrLoadSwitch<2048L" condition.

From the above analysis, we guess that "CPU write" is ignored or lost after "CLA read". which doesn't meet the "the lower action is not ignored but stalled and access is given after higher action is done".

However I'm not sure if the analysis is reasonable. Please give you comment about this. Thanks!

Best Regards

Rayna

Hi Rayna,

The older e2e is talking about specific context and hence the solution given was specific to that context. It is generally a good idea to refer to the TRM for the generic behavior.

Regarding the debug, Can you help me understand the flow of the code/debug a bit more?

1. How is the MdlCurrLoadSwitch value computed? Is it computed inside the Cla1Task3 loop based on the uiDcdcVoltK3/4/5 values?

2. Where did you read the values that is listed in Test results A/B/C/D from? CPU or CLA side? Can you list the values you have read from both sides when you hit the "1024L<MdlCurrLoadSwitch<2048L" condition?

Regards,
Praveen

Hi Praveen,

1. How is the MdlCurrLoadSwitch value computed? Is it computed inside the Cla1Task3 loop based on the uiDcdcVoltK3/4/5 values?

• This variable is from ADC over sampling signals in CLA, then translate to CPU as above code content.

2. Where did you read the values that is listed in Test results A/B/C/D from? CPU or CLA side? Can you list the values you have read from both sides when you hit the "1024L<MdlCurrLoadSwitch<2048L" condition?

• Actually, customer doesn't find a suitable method to confirm the test value is in same cycle. However, it could repeat the same abnormal phenomena, by fixing one of A/B/C/D value in code. 

Best Regards

Rayna

Rayna,

I want to suggest couple of experiments:

1. To make sure there is no data loss, ensure that the variables ‘uiDcdcVoltK3/4/5’ are updated only within the ISR. Once it is confirmed that these variables are not over-written elsewhere, Read the variables from the CPU side(may be through debugger or through SW) at the end of the ISR for few iterations. It should contain only one of the combinations of the values as set in the ISR. If this is the case, it means there is no data loss

2. To avoid any condition in which CLA reads the variables before CPU has written to it, Ensure to trigger the CLA task(that consumes the ‘uiDcdcVoltK3/4/5’ variables) towards the completion of ISR. This can be achieved by doing a software trigger of the task in which ‘uiDcdcVoltK3/4/5’ are used, at the end of the ISR. This ensures that the variables are written completely by CPU before the CLA can start consuming it. Right now in your setup, Is this CLA task where these variables are used different from Cla1Task3?

Regards,
Praveen

Hi Praveen,

From test result, customer found that issue may be influenced by system level factors.

However, customer would like to know that if "CPU write" data lost when "CPU write" and "CLA read" access to CPUtoCLARam area simultaneously.

Could you help with this confusion? Thanks! 

Best Regards

Rayna