TMS320F28069: Defining shared variables in CLA code - Part 2

Hi Luiz,

Can you share the code snippet how you are defining the variables in .cla file and .c file? The address to which it gets allocated to may vary in these 2 cases. I am suspecting it could be due to some hardware fault CLA is not able to access that address in the second case.

Regards,

Veena

You may check the .map file to get the address of the variable in both these cases

Hi Veena,

Thanks for your response.
The suspected variable is a Cla1ToCpuMsgRAM. so, it's the CPU that is unable to access CLA variables. Are you saying that there is a hardware fault in this particular memory section? 
Do you have any suggested method to verify the suspicion?
How to detect this hardware fault?


here's how I define them in both versions and generated map files.

cla-issue-20230419.pptx



Regards,
Luiz

Can you replace the DATA_SECTION pragma with #pragma LOCATION(addr) to force the address to the specified location. So that the address remains the same across these 2 options.

Regards,

Veena

The purpose of forcing the address to a specific location is to check whether that location has any hardware faults, correct?
As you can see here, that specific location (0x14b8) in V0 where no CLA issue is detected is used by cla_adc_data_dcdc_vout, and there is no problem with it.
Therefore, I am still confused about how this could happen.

*also note that V1 is following CLA dev guide on defining shared variables in C code.

best regards,
Luiz

Yes, it is to make sure there are no hardware faults at that address. 

Do you mean the variables defined in C code (the one on right) is the working one and the other one has issues?

Regards,

Veena 

No, the one on the right has an issue with accessing cla_lpf_ctrl_dcdc_vout. this V1 version defined the variables in C code.
I don't see any issue accessing the same variable (cla_lpf_ctrl_dcdc_vout) or variable in the same address (cla_adc_data_dcdc_vout) on the V0 version which defined shared variable in CLA code.

Regards,
Luiz

as for checking the hardware fault at the address (0x14b8). it is confirmed that in the V0 version, the address is used by cla_adc_data_dcdc_vout and I don't see any issue with it.


regards,
Luiz

update on this matter
1. issue in this variable is intermittent, as long as after reset the value is zero. it will always be zero until a power reset is performed.
    if after power reset the variable returns normal value, then it will be normal all the way. from this, i got an idea to detect the variable itsefl and reset the CLA by CLA soft/hard reset.

Does the idea look feasible?

2. it seems that the issue is not related to CLA variables placement, as I tried to shift the address allocation and the issue is still there.

   CLA1_MSGRAMTEST      : origin = 0x001480, length = 0x000040
   CLA1_MSGRAMLOW       : origin = 0x0014C0, length = 0x000040
   CLA1_MSGRAMHIGH      : origin = 0x001500, length = 0x000080
   
   //variable of interest is in Cla1ToCpuMsgRAM
   //tried to shift from 0x1480 to 0x14C0
   Cla1ToCpuMsgRAM  : > CLA1_MSGRAMLOW,   PAGE = 1
   CpuToCla1MsgRAM  : > CLA1_MSGRAMHIGH,  PAGE = 1

Luiz Ramelan1 said:

No, the one on the right has an issue with accessing cla_lpf_ctrl_dcdc_vout. this V1 version defined the variables in C code.

And this issue is producible only in one device, the same application runs fine in a different device right?

Regards,

Veena

on average the symptoms occur on 10% of our produced Boards. So, we have to halt our production line.

While rearranging some CLA shared variables (adding dummy data, shifting address) solved the issue for those MCUs, other previously normal MCUs are now encountering issues.

The inconsistencies with this CLA shared variable across numbers of MCU are becoming problematic. We can not keep changing the firmware every time we encounter issues with a new batch of MCUs. How can we ensure consistency and reliability among the MCUs and minimize the likelihood of encountering these issues in the future?

Now, I am trying to use CLA hard reset method when detecting 0 value during the first few seconds.

to update on this, resetting the CLA & CPU by software does not work. i used this register to reset CLA Cla1Regs.MCTL.bit.HARDRESET, and watchdog reset for CPU.

Only resetting by power (off-on) has a chance to get the normal value. on average, the CLA issue will come out 1 out of 10 times of power-on.

regards,
Luiz

Luiz Ramelan1 said:

on average the symptoms occur on 10% of our produced Boards

Can you confirm that it is the exact same .out running in all the boards?

Regards,

Veena

We’re using bootloader with TI format .txt file. And we add file integrity checking, so i can confirm it’s coming from the same out file.

regards,

luiz

Luiz Ramelan1 said:

1. issue in this variable is intermittent, as long as after reset the value is zero. it will always be zero until a power reset is performed.
    if after power reset the variable returns normal value, then it will be normal all the way. from this, i got an idea to detect the variable itsefl and reset the CLA by CLA soft/hard reset.

I am not sure if I understood this statement. On a power on reset the RAM memory might contain some junk value till the application initializes the variable to some value. Are you saying this initialization is not taking effect?

At what point are you checking whether the variable is 0 or not after reset?

Regards,

Veena

To add, Cla1ToCpuMsgRAM is read-only for CPU1. If the variable initialization happens in CPU1, the write will be ignored. I believe CLA is initializing these variables.

Regards,

Veena

Regarding the power reset, I mentioned it because the issue is inconsistent. We noticed the issue by reading a 0 value on the GUI after the board is turned ON, and it always shows 0 value and not just during initialization. Sometimes the issue can disappear when the board is turned off and then turned on again. Once we get a normal reading on the value, we can say the value is normal in that ON period.

To add clarification, the false reading is not limited to the initialization process. I understand that RAM memory can display junk values upon power reset, so I have been monitoring the variables after the MCU has completed initialization and is running in a loop. Recently, I discovered that the CPU is reading a value of 0x7F800000 from CLA, which translates to infinity in float. It may be due to data parsing, and it somehow appears as 0 value on the GUI.

The variable in question is a filtered value of ADCresult in the CLA task. I have verified that the ADCresult value, filter constants, and (n-1) value are all normal. However, the output filter value is experiencing issues and returning 0x7F800000, which translates to infinity in float. The value remains frozen at this value, while other normal variables slightly change over time due to the constantly changing ADCresult value.


best regards,
Luiz

The discussion is continuing offline.