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.

TMS320F28379D: Missing documentation on the CLB

Part Number: TMS320F28379D
Other Parts Discussed in Thread: C2000WARE, SYSCONFIG

Hi

I am doing a write-up on the possibilities/limitations of running dual core on a TMS320F28379D device for our company.

There is plenty of doc on how the internals of the CLB works, But I find it very hard to find decent documentation on how the CLB is connected in the 37xD devices.

- First example here is how the CLB is clocked, by searching these forums I find that apparently the CLB shares the clock with epwm1.

But it is not really clear if all four CLB's is clocked by the epwm1 as hinted by [1]

Or if it is CLB1 that shares with epwm1, and CLB2 with epwm2 a.s.o. as hinted by [3]

Or if I am on the totally wrong page, as the function refered to in [2] does not exist in c2000Ware for this device?

And I am chocked to only be able to such vital information, only by searching the forums, and not in either the reference manual nor the datasheet.

- Second related example, from [3] I find that the access rights of the CPU's to the CLB registers also follow the epwm registers, again not certain on the mapping, thou [] hints that is might be CLB1<->epwm1, CLB2<->epwm2 a.s.o. But again I find no documentation.

I get the impression that the CLB was thrown into the 37xD design in the last minute and someone forgot to tick the "update docs" task.

[1] https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1093256/tms320f28379d-clb-clock-and-epwm/4050802

[2] e2e.ti.com/.../4020620

[3] e2e.ti.com/.../3199001

  • Hi Martin,

    Thanks for reaching out to us about this. The F28379D was the first family to have this CLB peripheral, and it was only up until a few years ago where we enabled customer configuration for the CLB, where before it was only limited to a set of API calls that we had established. The F28379D has a Type 1 CLB, hence it has some restrictions on it that aren't present on other devices. 

    One such example would be the CPU ownership of the CLB, like you mentioned. CLB ownership has to be in tandem with the respective EPWM module, hence if you are wanting to use CLB2 on CPU2, you would also need to give access of EPWM2 to CPU2. Likewise, if you want CLB3 on CPU2, you would need to give control of EPWM3 to CPU2. 

    On dual core F2838X device, you can get away with just assigning the desired CLB ownership to CPU2 WITHOUT the need to assign the respective numbered EPWM module. 

    For clocking, it is a similar requirement, where CLB1 clock is derived from EPWM1, CLB2 clock is derived from EPWM2, CLB3 clock is derived from EPWM3, and CLB4 clock is derived from EPWM4, noted in (https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/963432/tms320f28388d-the-clock-source-of-clb/3560100). Other devices don't share this requirement

    One of the things in our backlog is actually creating more extensive documentation on CPU2 support for the CLB peripheral for our respective F28379D and F2838x devices so I am glad that you brought this up. For the clocking, we are releasing clocking support in our SysConfig tool which can also act as another reference for the CLB. I do believe that we are lacking some documentation, at least for the requirements of using CLB on F28379D, so if there is anything else that you notice, please feel free to reach out and I will try to add those ideas to our documentation

    Regards,

    Peter

  • Hi

    Thanks for the answer,

    While it did not really solve the issue, the completion of that backlog item probably will however, So i will mark it resolved.

    As a really nice to have, Has this backlog item gotten a  Jira number, that I can follow to get update on the progress?

    Also please fell free to send a draft for review, when you get there.

    Suggestion: Add some comment to the documentation in C200Ware driverlib functions, about this.

    Example 1

    //*****************************************************************************
    //
    //! Set global enable.
    //!
    //! \param base is the base address of a CLB tile's logic config register.
    //!
    //! This function enables the CLB via global enable register.
    //!
    //! \note CLBx shares the clock with EPWMx. So to enmable CLB1, do enable EPWM1 clock.
    //!
    //! \return None.
    //
    //*****************************************************************************
    static inline void CLB_enableCLB(uint32_t base)
    

    Example 2

    //*****************************************************************************
    //
    //! Enables a peripheral.
    //!
    //! \param peripheral is the peripheral to enable.
    //!
    //! Peripherals are enabled with this function.  At power-up, all peripherals
    //! are disabled; they must be enabled in order to operate or respond to
    //! register reads/writes.
    //!
    //! \note Note that there should be atleast 5 cycles delay between enabling the
    //! peripheral clock and accessing the peripheral registers. The delay should be
    //! added by the user if the peripheral is accessed immediately after this
    //! function call.
    //! Use asm(" RPT #5 || NOP"); to add 5 cycle delay post this function call.
    //!
    //! \note CLB and EPWM shares the same clock, to enable a CLB use the coresponding EPWM.
    //!       so a call with SYSCTL_PERIPH_CLK_EPWM1 will also enable CLB1, SYSCTL_PERIPH_CLK_EPWM2 will also enable CLB2 and so forth.
    //! \return None.
    //
    //*****************************************************************************
    static inline void
    SysCtl_enablePeripheral(SysCtl_PeripheralPCLOCKCR peripheral)

    You might want to phrase it shorter, but just having the CLB and EPWM mentioned here, would raise awareness and make me seek more info.

    It will not replace the need for a proper doc, but still way better than not knowing at all.

    I think these notes should also appear in the Sysconfig tool, in the CLB chapters.

  • Have a followup question.

    In the refenerence manual SPRUHM8I–December 2013–Revised September 2019

    in figure 26-5 (p2786) is the outputs named CLBx_OUT0 to CLBx_OUT15, but in the table below they are named  to CLBx_OUT7_0 and then CLBx_OUT1_0 to CLBx_OUT1_7, I assume that they map so CLBx_OUT9 == CLBx_OUT1_1 ?

    The CLB_OUT_EN register is a 32 bit register, and the text tells that each bit enables an output, but how does that map to the 16 outputs mentioned in chapter 26.3.

    Looking in driverlib function CLB_setOutputMask, there is provided defines (CLB_OUTPUT_xx) for all 32 bits also?

  • Hi Martin,

    You're exactly right, the output signals are written two different ways, but the idea is that CLBx_OUT9 == CLBx_OUT1_1, CLBx_OUT10 == CLBx_OUT2_1, etc. We're actually in the process of renaming these and clarifying these signals so that should be released in the next document update.

    In regards to CLB_OUT_EN, I believe only 16 bits are available from those 32 to access the CLB outputs, with each of those first 16 bits corresponding to each of the (replicated) CLB outputs.

    In our newer devices, there are actually 32 total outputs for the CLB, hence the entire CLB_OUT_EN register is used. I will check our issue board and see if this has been documented yet, but that will help us to clarify this point in the register tables and DriverLib software to eliminate confusion

    Regards,

    Peter