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.

ControlSuite CAN change information

Other Parts Discussed in Thread: CONTROLSUITE

Hello,

I'm currently working with a Delfino F2837xD part, and am trying to debug a CAN issue. We're currently using the v150 version of the ControlSuite drivers. In the newest release (v160), I see that the CAN drivers have been modified to "Fix CAN drivers to avoid issues with 32-bit reads/writes while using optimization".

My question: Where can I get more information on what made this change necessary? Maybe a Bug ID I can look at? I'm curious to know the symptoms of this bug that was fixed.  Does it always occur, or is it intermittent? Is there any way to see if this is happening in my code (a breakpoint I can set or variable I can watch)?

Thanks!

Mitch

  • Mitch,

    Since the CAN peripheral is designed for a 8 bit byte addressable architecture and C2000 devices are a 16 bit byte machine, an address/data bus bridge was added to translate the accesses so the C28x could interface with CAN.

    Having said that, at higher optimizations the compiler can convert a 32-bit write to a CAN register into two 16-bit accesses which can cause an issue using the CAN bus bridge which uses the byte addressing. Such symptoms could be that the lower 16-bits get set and the upper 16-bits do not. I've seen it more often when doing a 32-bit writes along with some bitwise operation (e.g. HWREG(address) |= 0xAAAABBBB can lead to only 0x0000BBBB in the register or possibly the data duplicated in the upper and lower word). Setting breakpoints and verifying that the registers are getting set with what you expect is one option of checking. Also, if you only see issues at higher optimization, that can also be a symptom.

    The current solution is to split the 32-bit writes/reads into two explicit 16-bit accesses. Looking at the CAN driver, you'll see this note on how that is achieved:
    "The CAN driver functions have been adjusted to explicitly use two 16-bit read/writes to access the full 32-bit register where HWREGH(base + offset) represents the lower 16-bits and HWREGH(base + offset + 2) represents the upper 16-bits. "

    This is however only a temporary solution as we have a compiler update in the works.

    Best Regards,
    Chris
  • Thanks for the info, that was very helpful. So am I correct in thinking that this would be a persistent issue, and not intermittent? For example, the example you gave was the line:

    HWREG(address) |= 0xAAAABBBB

    So if the complier optimized this line incorrectly, I would see the problem everytime this line of code would run in a specific build, correct? It would not be an intermittent problem.
  • Yes, that is an accurate understanding.

    Best Regards,
    Chris