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.

TMS320F28388D: CLB erratic behavior

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

Hi,

I'm having troubles to work the CLB module of the 28388. The CLB modules are not always working as expected, counters can have erratic behavior (count not incrementing when expected, reset when not supposed to, ...), etc. 

I sometime have a working configuration, but a slight change in this configuration breaks everything again:

  • removing/adding a CLB module can impact the other CLBs
  • changing a LUT table config is affecting the global behavior of that CLB.
  • ...

I am working with CCSv12, Sysconfig 1.13, all the CLB config is done graphically in SysConfig and then I call Board_init() from my main file after clocks and peripherals are properly activated.

Is there any obvious reason why I can't have a stable CLB behavior? The worst part is to see a counter return to 0 when the reset input is forced to 0 and the mode1 input to 1...

Thanks,

Stephane

  • Hi Stephane,

    When you say that it acts erratically, do you mean that CLB exhibits different behavior even with no changes to the configuration? Or do you mean that anytime you change the configuration of the CLB, the CLB functions differently than what you had expected it to?

    This seems like a complex issue, would you be able to provide your CLB configurations, or at least what signals you are using as the enable and reset of the CLB counter, and the LUTs? What are you working to implement with the CLB? 

    I don't believe your software versions would be affecting anything, but could you let me know which C2000Ware version you are using? If you are using 4.01.00.00 (the latest as of writing this), then you may want to try CCSv11.1 as that was the version that was available when that SDK version was released. Although I don't believe this would affect anything since the CLB Tool was not changed in the last update.

    Regards,

    Peter

  • Hi Stephane,

    Any updates on this? Were you able to resolve the CLB behavior?

    Regards,

    Peter

  • Hi,

    The CLB issue is currently under control after removing some complex input settings (I had some input signals that were used twice, once as raw signal and another time as filtered signal). I'm not sure if it was the root cause, but it looks more stable now, I haven't seen any more trouble after a couple of iterations on my CLB block design.

    Regards,

    Stephane

  • Thanks for the update on this Stephane. Glad to hear that you are happy with your current CLB iteration. If you are having issues with the input, I recommend reviewing the TRM for the inputs you are using and configuring input synchronization for any async inputs. We realized that this was not emphasized enough as it should in our documentation and are currently working to update it to emphasize the need to enable this synchronization

    Regards,

    Peter