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.

HALCoGen issue with tms570ls04 CAN driver

Other Parts Discussed in Thread: TMS570LS0432, HALCOGEN

Hello,

After updating from 03.02 to recent 03.08 and regenarating code my CAN communication program stopped functioning. I am using TMS570LS0432 HDK.

Only the first message is read from the bus, and any further attempts to read fail.

After going over diffs between versions, I eventually tracked down the issue to this CAN init code:

canREG1->CTL = (uint32)0x00000000U
| (uint32)0x00000000U
| (uint32)((uint32)0x00000005U << 10U)
| (uint32)0x00020043U;

The operation in bold is missing from old version, and deleting this part solved the issue, allowing me to continuously read from the CAN bus.

Is this misconfiguration on my part? A bug?

Thanks,

Oron

  • Oron,

    Can you confirm which Halcogen version you are using.
    The latest one is 03.08.01
    On version 03.08.00 some issues were found and fixed in 03.08.01

    Please let me know and I will forward your question to our HalCoGen team.

  • Yes, sorry for not being specific. I am using version 03.08.01

  • Oron,

    This statement is controlled by the check box in CAN1 General Tab (Enable RAM Parity On/Off)

    In case of RAM Parity enable is On the code generated is:

    canREG1->CTL = (uint32)0x00000000U
    | (uint32)0x00000000U
    | (uint32)((uint32)0x0000000AU << 10U)
    | (uint32)0x00020043U;

    In case of RAM Parity enable is Off the code generated is:

    canREG1->CTL = (uint32)0x00000000U
    | (uint32)0x00000000U
    | (uint32)((uint32)0x00000005U << 10U)
    | (uint32)0x00020043U;

    Out of reset, the DCAN module has the bit 13-10 of DCAN_CTRL set to 0x5 (Parity disable)
    So this statement: | (uint32)((uint32)0x00000005U << 10U) should not change anything.

    Please let me know if this clarify your question?

  • Yes, enabling RAM parity fixed this, and now the CAN transceiver works properly again.

    Still, I do not understand two things:

    1. What is the meaning of RAM parity? why would this prevent me from properly reading from the CAN bus?
    2. How am I or other beginning developers expected to guess that RAM parity should be enabled in order to get things to work? Why was this suddenly changed in HALCoGen in recent update?

    Thank you,

    Oron

  • Oron,

    Back to your original post, you were saying that the following statement was introduced in Halcogen 03.08.01 and because of that your code is not working.

    canREG1->CTL = (uint32)0x00000000U 
    | (uint32)0x00000000U 
    | (uint32)((uint32)0x00000005U << 10U)                        // Default RAM Parity disable
    | (uint32)0x00020043U;

    As I said in a previous reply, this code does not change the default out of reset value for DCANCTL register.
    Here is an extract from the TRM:

    The Value 0x5 in PMD disables the parity checking.

    Here is another extract from the TRM concerning DCAN Parity.

    It is up to the end user to decide to use or not parity. In safety application, it is recommended to enable the parity.

    Please let me know if you need more details.
    I will be interested to see your Halcogen project. Could you share your CCS project so I can have a look?

  • Jean-Marc, thank you for providing all this info.

    Seems odd that disabling parity would cause the CAN driver to only read one packet and then stop functioning... I must be doing something wrong :)

    The function "argusIsDataReady()" in argusCan.c is where the CAN bus is tested for available packets, and does not function properly if parity is disabled.

    I've attached the CCS and HCG project in this post.

    Thank you,

    Oron

    Edit: uploaded a misconfigured project previously... reattached

    0003.DCAN.rar