TMS320F280025: DCL library functions control parameter updates

Hello,

Due to US holiday, please expect a response by 20th February.

Thanks & Regards,

Sinchita

Hi Bo,

Thank you for catching a mistake that goes unnoticed, the CCS attribute is indeed in the 20th byte of the struct after alignment. I apologize for the such an inconvenience, and I'll make sure this fix get reflected in our next release. All other futils looks fine after checking, so there's no other changes required. 

Once again thanks a lot! Please let me know if there's any other problems and questions you have regarding our libraries.

Best,

Sen Wang

Sorry to bother you. I came up with some problems when using VCRC, the cause may also has some relationship with fupdatePI. Here are my test steps:

1.I calculated and got the right CRC value.Then I called DCL_updatePI and changed the PI parameters. I calculated and got the right CRC value again;

2.I calculated and got the right CRC value.Then I called DCL_fupdatePI and changed the PI parameters. I calculated CRC value again, but I can't get the right CRC value any more.

Hi Bo,

Sorry about the delay, let me reach out to VCRC experts and see if there's any potential caveats that I'm not aware of. I'll get back to you once I receive a response.

Best,

Sen Wang

Hi Bo,

There isn't any known issue regarding the reentrancy of the VCRC module, nonetheless, upon closer inspection of the the assembly code, it seemed that one line is missing from the _DCL_fupdatePI .asm func:

_DCL_fupdatePI:
        .asmfunc
        PUSH        ST0                 ; save flags
        PUSH        XAR0                ; save XAR0
        PUSH        XAR7                ; save XAR7
        PUSH        ST1                 ; preserve INTM
        MOVL        XAR7, @XAR4         ; XAR7 = &p
        ADDB        XAR7, #20           ; XAR7 = &CSS
        MOVL        XAR0, *XAR7         ; XAR0 = &tpt
        MOVL        ACC, *+XAR0[4]      ; ACC = CSS.sts
        AND         ACC, #1             ; mask bit 0
        BF          PI_EXIT, EQ         ; skip if zero
        TCLR        *+XAR0[4], #0       ; clear STS_UPDATE_PENDING flag
        MOVL        XAR0, XAR7          ; XAR0 = &CSS
        SUBB        XAR0, #2            ; XAR0 = &SPS
        MOVL        XAR7, *XAR0         ; XAR7 = &Kp
        SETC        INTM                ; block interrupts
        MOVL        ACC, *XAR7++        ; SPS.Kp -> ACC
        MOVL        *XAR4++, ACC        ; update KpUmax
        MOVL        ACC, *XAR7++        ; SPS.Ki -> ACC
        MOVL        *XAR4++, ACC        ; update Ki
        ADDB        XAR4, #2            ; XAR4 = &Umax
        MOVL        ACC, *XAR7++        ; SPS.Umax -> ACC
        MOVL        *XAR4++, ACC        ; update Umax
        MOVL        ACC, *XAR7++        ; SPS.Umin -> ACC
        MOVL        *XAR4++, ACC        ; update Umin
        ADDB        XAR4, #2            ; XAR4 = &Imax
        MOVL        ACC, *XAR7++        ; SPS.Imax -> ACC
        MOVL        *XAR4++, ACC        ; update Imax
        MOVL        ACC, *XAR7          ; SPS.Imin -> ACC
        MOVL        *XAR4, ACC          ; update Imin
        CLRC        INTM                ; <<---Add this line
PI_EXIT:
        POP         ST1                 ; restore INTM
        POP         XAR7                ; restore XAR7
        POP         XAR0                ; restore XAR0
        POP         ST0                 ; restore flags
        LRETR
        .endasmfunc

Can you please try adding the following line right before PI_EXIT branch and see if it still behaves abnormally?

        CLRC        INTM                ;

I apologize for the inconvenience, please let me know if this resolves the issue. 

Best,

Sen Wang

Thank you for your reply. I add this line and try again, here are some of my test results below:

1) Calling of DCL_updatePI does't affect VCRC;

2) Calling of DCL_fupdatePI(with or without CLRC INTM) affects VCRC result;

3) Calling of DCL_fupdatePID(with or without CLRC INTM) affects VCRC result;

Thank you so much for your feedback Bo,

Due to bandwidth limitation, I wouldn't be able to replicate and debug this particular issue until next week. I'll keep you posted once I figure out the root cause to the issue. 

But for now we can stick with DCL_updatePI, hope that is fine with you.

Best,

Sen Wang 

Hi Bo, I apologize for the delay.

Just to double check, is the flag --isr_save_vcu_regs under Processor Options enabled?  

May I know the size, polynomial that you're using?  Do you also happen to use the linker-generated CRC tables that produces linker-computed value? Feel free to message me directly about the specifics if it isn't appropriate to disclose these informations in public.

Best,

Sen Wang

1. --isr_save_vcu_regs is not set as the pictures below:

2.Hear is my CRC configuration with Sysconfig, using CRC-16-MODBUS , 14 bytes and polynomial is 0x8005.

3. The final value I used is got from CRC_bitReflect(BswCrc_VCRC0_Handle->crcResult,16);

4. I have done some more tests ,it may have relationship with the function above:

    4.1) I can get the right CRC Value BswCrc_VCRC0_Handle->crcResult after calling fupdate function (no matter  --isr_save_vcu_regs on/off or not setting );

    4.2)  The value got from function CRC_bitReflect(BswCrc_VCRC0_Handle->crcResult,16) is wrong aftter calling fupdate function;

    4.3) e.g. Calculate 0x01-0x14 CRC Value, VCRC output is 0x89D3, feflect value is 0xCB91; After calling fupdate, VCRC output is 0x89D3 also, but reflect value  is always 0xDFA3;

5. Another question about VCRC module

   There is only VCRC module in this device according to DataSsheet, but the header files generated from SysConfig includes VCU2 header files. Should I use the functions from vcu2xxx.h? If I can not use these functions, why can I get the right CRC reflect value before calling fupdate. 

Hi Bo,

Got it, Thank you so much for the information.

Regarding the VCU2, VCRC is only a subset of VCU2. Unfortunately for F28002x devices only VCRC is implemented so you couldn't use the other features that VCU2 has (like Viterbi, VCU2 based FFT, ReedSolomon etc.). But feel free to use any functions in VCU2 that deals with CRC.

Best,

Sen Wang

Thanks. I do not use other features of VCU2, except  CRC_bitReflect function;

Sorry for a mistake in the reply above, the raw value I use to calculate CRC is 0x01,0x02....0x0E(1~14), not 0x01-0x14.

Hi Bo,

Apologies for the long delay, thought I've replied with a follow-up message but it was never sent.

I tried your setup configuration and wasn't able to replicate the issue, both CRC_runConfigpolyBytes and CRC_bitReflect were consistent regardless of which DCL function was ran. But if you were using interrupts, please made sure your --isr_save_vcu_regs were set in order to save / restore vcu regs in an event of isr. 

Best,

Sen Wang

Hi Sen,

Sorry for the long delay, because I am busy with some coding things these days.

I tried a new CCS project named <DCL_Test1> . The version of  CCS, C200Ware and Compiler version was recorded in the main.c file.

1. No ISRs in this project;
2. --isr_save_vcu_regs is set to on;
3. Change  offset to 20th byte of the struct after alignment in function  _DCL_fupdatePI （in file DCL_futils.asm）;

The right CRC value is 0xCB91;

After calling DCL_updatePI, the result is not affected, it is still 0xCB91.

After calling DCL_fupdatePI, the result is always 0xF303（Different from Previous Test, but it is always the wrong value 0xF303）

DCL_Test1.zip

Hi Bo,

Thank you so much for the provided example, let me try and replicate the issue and I'll get back to you.

Best,

Sen Wang

Bo,

I just got pulled into this issue, so I have a few questions for you.

1. Could you summarize exactly what functions are called, and in what order, to perform the CRC computation?

2. Could you specify exactly where in the above flow the updatePI or fupdatePI function is called?

Thanks,

Sira

You can see the demo I provided<DCL_Test1.zip> and the reply above in this issue.

I summarize the steps here:

1.Set variable <Ge_U_Flag[0]> in Expressions View, you can get CRC Value once, the right CRC Value <GeBswCrc_U_Res> is 0xCB91;

2.Set variable <Ge_U_Flag[1]> in Expressions View, you can run DCL_fupdatePI once. If you get CRC Value again setting <Ge_U_Flag[0]>, the final <GeBswCrc_U_Res> is not right this time;

3.Change function DCL_fupdatePI(&AswDcc_Controller1_VHBus) to DCL_updatePI(&AswDcc_Controller1_VHBus), compile and download the new program again. This time no matter you called DCL_updatePI or not , the CRC Value <GeBswCrc_U_Res> is always the right value 0xCB91;

Bo,

Thanks. I looked at the code. I see you are performing the CRC compute followed by a bitreflect(), followed by updatePI/ fupdatePI in an infinite loop.

A couple of comments/questions:

1. In the erroneous case with fupdatePI, have you determined that BswCrc_VCRC0_Handle->crcResult is still correct, whereas the output of CRC_bitReflect() is incorrect?

2. What is the value of BswCrc_VCRC0_Handle->crcResult in the case of updatePI and fupdatePI?

Thanks,

Sira

BswCrc_VCRC0_Handle->crcResult is always right after calling fupdatePI/updatePI. Value got from CRC_bitReflect() is wrong after calling fupdatePI, but it is right after calling updatePI.

I have replied in the above reply of this issue 2 months ago as below:

3. The final value I used is got from CRC_bitReflect(BswCrc_VCRC0_Handle->crcResult,16);

4. I have done some more tests ,it may have relationship with the function above:

    4.1) I can get the right CRC Value BswCrc_VCRC0_Handle->crcResult after calling fupdate function (no matter  --isr_save_vcu_regs on/off or not setting );

    4.2)  The value got from function CRC_bitReflect(BswCrc_VCRC0_Handle->crcResult,16) is wrong aftter calling fupdate function;

    4.3) e.g. Calculate 0x01-0x14 CRC Value, VCRC output is 0x89D3, feflect value is 0xCB91; After calling fupdate, VCRC output is 0x89D3 also, but reflect value  is always 0xDFA3;

 Note: The version of  CCS, C200Ware and Compiler version is not the same as <DCL_Test1.zip> , and the wrong value is not the same.

Hi Bo,

Thank you for your observation, I was also able to replicate this issue with CRC_bitReflect and fupdatePI. We're having an active internal discussion with the broader team and will get back to you when we have a conclusion in about a day or so.

I really appreciates your patience on this matter.

Best,

Sen Wang