• Locked Locked
  • Replies 3 replies
  • Subscribers 30 subscribers
  • Views 684 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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 04.06.00 possible bug in DCAN FIFO initialization

user3996705
Prodigy 40 points
Other Parts Discussed in Thread: HALCOGEN

The release notes for HALCoGen says it is including support for DCAN FIFO configuration. As I'm using this feature, I upgraded to the new version to check how the DCAN FIFO support looks like.

At first glance, it seems that the only support added is a checkbox in every DCAN mailbox which allows to set/reset the EOB bit. I migrated my project based on HALCoGen 04.05.02 to 04.06.00, and after code generation I found that the code generated for initCan() seemed wrong.

For every CANx mailbox, V 04.05.02 generated the following line of code:

canREG2->IF1MCTL = 0x00001080U | (uint32)0x00000400U | (uint32)0x00000000U | (uint32)8U;

The value 0x00001080U already includes the EOB bit set so every DCAN mailbox is independent by default, thus it can not be used as part of a FIFO unless you create your own custom initCan() function, which is what I did.

With HALCoGen 04.06.00, after checking the EOB checkbox of some DCAN mailboxes in the UI and generating code, the affected lines were changed to:

canREG2->IF1MCTL = 0x00001080U | (uint32)0x00000400U | (uint32)0x00000000U | (uint32)0x00000080U | (uint32)8U;

I could see there was a new fieId added with the value 0x00000080U, but I had the suspect that the 0x00001080U value would remain unchanged even after unchecking the EOB checkbox, so I repeated the code generation after clearing the EOB of the related DCAN mailboxes in the UI. The result was:

canREG2->IF1MCTL = 0x00001080U | (uint32)0x00000400U | (uint32)0x00000000U | (uint32)0x00000000U | (uint32)8U;

It removed the EOB bit from the 0x00000080U value, but the 0x00001080U value still had the EOB bit set, so the generated code was useless.

I repeated the test by creating a new project from the scratch, to see if the problem was caused by migrating the project from a previous HALCoGen version. The result was the same.

Could you please check this one?

Thanks in advance

Antonio López

  • TI__Guru**** 183536 points
    Hi Antonio,
    thanks for the finding. I can confirm the same. I use CAN1. Regardless of the EOB bit in the UI the generated code always has the bit7 set due to the 0x00001080U. Below is what I generated with the EOB unchecked. I will report to HalCoGen team.

    canREG1->IF1MSK = 0xC0000000U | (uint32)((uint32)((uint32)0x000007FFU & (uint32)0x1FFFFFFFU) << (uint32)0U);
    canREG1->IF1ARB = (uint32)0x80000000U | (uint32)0x40000000U | (uint32)0x20000000U | (uint32)((uint32)((uint32)1U & (uint32)0x1FFFFFFFU) << (uint32)0U);
    canREG1->IF1MCTL = 0x00001080U | (uint32)0x00000000U | (uint32)0x00000000U | (uint32)0x00000000U | (uint32)8U;
    canREG1->IF1CMD = (uint8) 0xF8U;
    canREG1->IF1NO = 1U;
  • in reply to Charles Tsai
    Prodigy 40 points
    Hi Charles,
    Thanks for your quick answer.

    In order to keep the generated code compatible with earlier HALCoGen releases, It would be nice if you tell to HALCoGen team to let EOB checkboxes be checked by default. Also I think strange CAN bugs could happen if all EOB bits are reset by default and you forget to set them by hand.

    Regards,

    Antonio López
  • in reply to user3996705
    TI__Guru**** 183536 points
    Hi Antonio,
    Yes, your comment is valid. People who migrate from older version to latest version may not pay attention that all EOB are unchecked now. The default should be to check all of them in UI.