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.

TMS320F280049: CCP + Digital output holding high

Part Number: TMS320F280049

Hi,

I understand that the CCP functionality is Mathworks responsibility but I was hoping you could shed some light on my issue as the software seems to behave properly but the hardware doesn't.

My Mathworks support request is here in high detail of what was tested and what wasn't: https://uk.mathworks.com/matlabcentral/answers/582761-tms320f280049-ccp-parameters-not-working?s_tid=srchtitle

In sum, I have managed to make CCP work, I can monitor the signals and I can change parameters, or at least partially.

The point that I think it may be a TI question is that in the following picture HOP_Doh_Do3_bool doesn't change GPIO9 if the source of this signal was modified via CCP:

OPP_HeartBeat_Pre_bool is cycling between 1 and 0 every second and the output GPIO9 works correctly, also cycling: 

If I change, via CCP, OPPc_HeartBeat_bool_OvrEn_bool, then OPP_HeartBeat_bool assumes the value of OPPc_HeartBeat_bool_OvrVal_bool =0 and GPIO9 goes low.

If I change  OPPc_HeartBeat_bool_OvrVal_bool to 1, then HOP_Doh_Do3_bool Goes back to true and so does GPIO9 but it doesn't go low again even with OPPc_HeartBeat_bool_OvrVal_bool and HOP_Doh_Do3_bool are both false.

Software wise OPPc_HeartBeat_bool_OvrEn_bool has no effect from the moment it goes true since even if I make it false, OPP_HeartBeat_bool  doesn't follow OPP_HeartBeat_Pre_bool as it did initially before any override was changed.

I've been through memory allocation as I cannot understand how the switches stop working but maybe there's some other issue here since the GPIO simply doesn't follow what HOP_Doh_Do3_bool from the moment it goes through a switch.

All my parameters are on RAMGS_DATA which seems correct (Global shared RAM).

This seems to be related to the true value, from false to true it seems to be fine but not the other way around.

I would very much appreciate any suggestion.

  • Celso,

    I believe there is a way to view the C code that Embedded Coder generates for the above logic blocks. If you could select this option and post the C code we can take a look at it to better understand how the logic switch has been implemented in SW/HW on the C2000.

    Best,
    Matthew

  • Hi Matthew,

    Here's the GPIO bit:

        /* S-Function (c280xgpio_do): '<S122>/Digital Output GPIO7' */
        {
          if (HOP_Doh_Do5_bool)
            GpioDataRegs.GPASET.bit.GPIO7 = 1;
          else
            GpioDataRegs.GPACLEAR.bit.GPIO7 = 1;
        }
    
        /* SignalConversion: '<S122>/Signal Conversion3' */
        HOP_Doh_Do3_bool = CcuBrd_f28004x_ert_B.OPP_HeartBeat_bool_f;
    
        /* S-Function (c280xgpio_do): '<S122>/Digital Output GPIO9' */
        {
          if (HOP_Doh_Do3_bool)
            GpioDataRegs.GPASET.bit.GPIO9 = 1;
          else
            GpioDataRegs.GPACLEAR.bit.GPIO9 = 1;
        }
    

    And here is the heartbeat bit:

        if (OPPc_HeartBeat_bool_OvrEn_bool) {
          OPP_HeartBeat_bool = OPPc_HeartBeat_bool_OvrVal_bool;
        } else {
          OPP_HeartBeat_bool = OPP_HeartBeat_Pre_bool;
        }

    these look fine to me.

    I don't believe it's the generated code as I've said before the heartbeat is cycling and the output works fine, ON and OFF, as soon as I override it, then it stops working.

    It's like I cannot clear OPPc_HeartBeat_bool_OvrEn_bool even though the calibration tool tells me it is clear.

  • I'll ping the MW team to take a look at this in parallel; would you be able to see where OPP_HeartBeat_Pre_bool is set?

    Best,
    Matthew

  • Hi Matthew,

    I can't pin down the exact extract of code as this goes through a few delays and data type conversions but previous to the override, all works as expected. The following picture shows this, I changed OPPc_HeartBeat_bool_OvrEn_bool to 1 and then back to 0, you can see the "Pre" continues oscillating (green) while the "Not Pre" (red) stops when OPPc_HeartBeat_bool_OvrEn_bool is true, but it doesn't resume when OPPc_HeartBeat_bool_OvrEn_bool is false:

  • Celso,

    I had a email with the MW team, they mentioned they were debugging this issue with you as there are some CCP specific things in play here.  I'm going to mark as TI thinks resolved with that assumption; but if there are still open actions for us you can reply back and it will notify me of your post.

    If there is anything helpful from the debug you'd like to share on the E2E for other C2000/MW users I would encourage that as well, but totally up to you.

    Best,
    Matthew

  • Hi Matthew,

    Indeed, I spent 3h on a call trying to debug this.

    The picture below shows CANape (CCP tool) on the left and Memory browser on CCS on the right.

    Using CCP I changed the values of OPPc_Heartbeat_bool_OvrVal_bool, OSMc_State_enum_OvrEn_bool, WCHc_DcBus1CttrReq_bool and WCHc_DcBus2CttrReq_bool  to true and they all changed from 0000 to the bolean value preceded by the last byte of the memory address, indicating that the CCP block is not decoding it properly before writing into the memory.

    I changed the value back to false and the last bit indeed changes, but the first byte remains the parameter’s address last byte:

    We don't have a solution yet as I can't change the CCP block myself but I hope Mathworks are revising that block.

    Thank you for chasing this for me.

    Kind Regards

    Celso

  • ccp_utils.zip

    After a lot of debugging I finally found the solution and now I can calibrate all data types.

    Copy the file attached into C:\ProgramData\MATLAB\SupportPackages\R2020a\toolbox\target\supportpackages\tic2000\src.
    I've already informed Mathworks so they can release a bug fix soon.
    You're welcome! ;P