This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

C2000-DIGITAL-CONTROL-LIBRARY: DCL_runClamp_C1 stucks when Umax is updated

Part Number: C2000-DIGITAL-CONTROL-LIBRARY

Hi all,

I'm using DCL_runDF22_C2 and DCL_runDF22_C3 and DCL_runClamp_C1 to control my PSFB. I noticed something for DCL_runClamp_C1 .

Fullscreen
1
2
3
4
5
6
// Clamping and saturation
float32_t PSFB_cntlMax, PSFB_cntlMin;
uint16_t PSFB_saturation_flag;
float32_t PSFB_icommand_Set_pu, PSFB_irampmax_Set_pu;
PSFB_saturation_flag = DCL_runClamp_C1(&PSFB_icommand_Set_pu, PSFB_cntlMax, PSFB_cntlMin); //clamp
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


Q1) Why can't I define parameters like PSFB_cntlMax, PSFB_cntlMin andPSFB_icommand_Set_pu as VOLATILE? If I define these parameters, I get warning after building code.

Q2) In my developed board: At my software, I need to adjust output current and at a slow task I need to update PSFB_cntlMax parameter. If I update PSFB_cntlMax online, it works fine and limits my current. However, later on, if I also update my output set voltage, which is input of DF22, my controller stucks and cannot adjust output voltage. My psfb works alway in current limit mode and the clamp out is always stays at Umax although error output becomes negative

      Q2.a ) How can it be?

      Q2.b ) It doesn't stuck at same condition if I use demoboard F280039C?

Q3) I fixed above problem as doing PSFB_cntlMax as constant as 1.0f and I don't change it anymore. I change clamp max and min by using below function.

The updated parameter in slow task is PSFB_PCMC_Cset_Slewed.

// Clamp max/min
PSFB_icommand_Set_pu = (PSFB_icommand_Set_pu > PSFB_PCMC_Cset_Slewed)?
PSFB_PCMC_Cset_Slewed:PSFB_icommand_Set_pu;

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
PSFB_vLVBus_sensed_pu = ((float32_t)(Measurements.V_LVBat)) * PSFB_ADC_PU_SCALE_FACTOR; //yk pu
PSFB_vcommand_Set_pu = PSFB_LV_Vset_Slewed / (PSFB_VLVBUS_MAX_SENSE_VOLTS); //rk
PSFB_error_vLVBus_pu = PSFB_vcommand_Set_pu - PSFB_vLVBus_sensed_pu; //error
PSFB_icommand_Set_pu = DCL_runDF22_C2 (&PSFB_gv, PSFB_error_vLVBus_pu); //run compensator
PSFB_saturation_flag = DCL_runClamp_C1(&PSFB_icommand_Set_pu, PSFB_cntlMax, PSFB_cntlMin); //clamp
if(PSFB_saturation_flag == 0)
{
DCL_runDF22_C3(&PSFB_gv, PSFB_error_vLVBus_pu, PSFB_icommand_Set_pu);
}
// Clamp max/min
PSFB_icommand_Set_pu = (PSFB_icommand_Set_pu > PSFB_PCMC_Cset_Slewed)?
PSFB_PCMC_Cset_Slewed:PSFB_icommand_Set_pu;
PSFB_icommand_Set_pu = (PSFB_icommand_Set_pu < PSFB_cntlMin)?
PSFB_cntlMin:PSFB_icommand_Set_pu;
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Q3.a) How this solution fixed my problem? 

  • Hi Gokhan,

    I'll also answer your questions in order:

    Q1) You can use violatile keyword, but the compiler will complain about passing violatile parameters in non-violatile parameters like DCL_runClamp_C1. You can fix it by adding the function parameters with the keyword violatile.

    Q2) While I can't speculate what might be the cause without knowing the code strcture, if your code doesn't use ISR and everything goes by chronological order then it shouldn't happen. But if ISRs are involved and you're sharing values amongst different routines (like your PSFB_icommand_Set_pu and PSFB_cntlMax in this case). Then it's recommended to have some mutux mechanism blocking the writes while the values are being read. What you've described sounds like a timing issue for me, it is persistent and could cause an issue on one setup, while it doesn't seem to be causing an issue on another setup. 

    Q3) The only different here is that we are accessing PSFB_icommand_Set_pu's value directly rather than passing the address to the function. Is your PSFB_icommand_Set_pu declared as a local variable? If so can you try declaring the variable as a tranlation-unit scope (global variable)? 

    Best,

    Sen Wang