Author Topic: CAN bus on K20  (Read 1043 times)

Offline Felix

  • Newbie
  • *
  • Posts: 18
    • View Profile
CAN bus on K20
« on: January 10, 2018, 08:26:41 PM »
Hey Mark,
I played around a lot with uTasker today and it fits our requirements very well for some further project work.
The only thing, I didnt get to work is the CAN interface. Is it already supported for TWR-K20D72M at all?
I've enabled the CAN_INTERFACE as presented in the CAN users guide, but in the menu "CAN commands" of the serial output console, no CAN commands are shown (the menu is empty). I've also tried to include can_tests.h manually, without success.
Could you give me a hint how to proceed?
Thanks for your work on this great project and regards
Felix

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 2955
    • View Profile
    • uTasker
Re: CAN bus on K20
« Reply #1 on: January 10, 2018, 10:57:37 PM »
Felix

I just tried and the CAN menu has the commands in it.

   CAN commands
===================
up             go to main menu
can            Send to default [ch] <data hex>
can_s          Send to id [ch] <id> <data hex>
can_e          Send to ext. id [ch] <id> <data hex>
can_r          Request remote default [ch]
can_rs         Request remote id [ch] <id>
can_re         Request remote ext. id [ch] <id>
can_f          Free remote rx when no response
can_d          Deposit remote message [ch] <data hex>
can_c          Clear remote message [ch]
help           Display menu specific help
quit           Leave command mode


The entries are dependent on CAN_INTERFACE so either this hasn't been set correctly or you need to do a clean and rebuild due to a problem with the make file not rebuilding correctly.

Regards

Mark

Offline Felix

  • Newbie
  • *
  • Posts: 18
    • View Profile
Re: CAN bus on K20
« Reply #2 on: January 11, 2018, 08:26:13 AM »
Hey Mark,
thank you. You gave me the right approach. It was about a wrong path configuration in my project. Now the menu entries are shown.
Best regards!

Offline Felix

  • Newbie
  • *
  • Posts: 18
    • View Profile
Re: CAN bus on K20
« Reply #3 on: January 12, 2018, 02:17:31 PM »
Hey Mark,

CAN bus is now working in both directions via terminal debug interface.
My problem is now that receiving of CAN messages is limited to one single ID, defined as tCANParameters.ulRxID in can_test.h.
In the CAN user manual you wrote, that the usage of mask bits is also possible but hardware specific:
Code: [Select]
tCANParameters.ulRxIDMask = CAN_STANDARD_MASK;This doesn`t work for me, at least for the terminal debug interface.
Can I use CAN receiving just for one ID for my hardware (TWR-K20D72M) or is this just an issue of the can test functions?

Thank you and best regards
Felix

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 2955
    • View Profile
    • uTasker
Re: CAN bus on K20
« Reply #4 on: January 12, 2018, 03:21:36 PM »
Felix

You need to read the FlexCAN description to see what exact capabilities the controller has for filtering messages.
However, the
tCANParameters.ulRxIDMask = CAN_STANDARD_MASK;
setting means that all of the ID bits are used to match acceptance in a rx buffers, and there is thus only one ID accepted, which is what you have confirmed.

If this were to be set at 0x7fe (non extended addressing) the LSB would not be checked and so 2 IDs would be accepted.
With a value 0x000 it means that no checking is made and so all messages are accepted.

The filtering strategies are quite different for different controllers - see the bxCAN overview in the appendix of the CAN document for a comparison.

Finally, take a careful look at the CANx_CTRL2 register which has a number of options. This register is left at its default state. It may however cause some restrictions like this concerning matching or could be used to increase its flexibility.

Good luck

Regards

Mark



Offline Felix

  • Newbie
  • *
  • Posts: 18
    • View Profile
Re: CAN bus on K20
« Reply #5 on: January 12, 2018, 06:11:31 PM »
Hey Mark,
thanks for the hint with the RX mask, but changing
tCANParameters.ulRxIDMask = 0x7FF to
tCANParameters.ulRxIDMask = 0x000
in can_tests.h is without any effect for me. It´s still just one ID that passes the filter.
In my application I dont`t need filtering so the default settings in CAN0_CTRL2 should be okay.
Sorry but I'm not that  familiar with the code yet, to understand what I´am doing wrong.
Cheers Felix

Offline Felix

  • Newbie
  • *
  • Posts: 18
    • View Profile
Re: CAN bus on K20
« Reply #6 on: January 24, 2018, 12:41:24 PM »
Hi Mark,

I´ve found out that my issue has something to do with the way the acceptance mask registers are set in your code. For me, the following code called in fnConfigCAN (located in kinetis_CAN.h) is without effect:
Code: [Select]
if (ptrFirstAllocated == ptrMessageBuffer) {
                    ptrCAN_control->CAN_RX15MASK = pars->ulRxIDMask;     // first allocated receiver buffer has special mask
                }
                else if (ptrSecondAllocated == ptrMessageBuffer) {
                    ptrCAN_control->CAN_RX14MASK = pars->ulRxIDMask;     // second allocated receiver buffer has special mask
               }
                else {
                    ptrCAN_control->CAN_RXGMASK = pars->ulRxIDMask;      // initialise general acceptance mask for use with subsequent buffers
                }

If I call the same code within the fnInitCAN function, everthing works as expected. I do not really understand why it has to be called from there, because both functions are called one after another. Maybe you have an idea ?!

In my case, I'm now very happy with my great working CAN interface.  :)

Thank you and best regards
Felix

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 2955
    • View Profile
    • uTasker
Re: CAN bus on K20
« Reply #7 on: January 24, 2018, 08:33:07 PM »
Hello Felix

I am pleased that the CAN interface looks to be working well for you.

However I presently have no explanation about the difference due to the calling location - I have noted this observation and will do some additional investigation the next time that I am working with CAN.

Regards

Mark