MCUXpresso combine mcan and ethernet

cancel
Showing results for 
Search instead for 
Did you mean: 

MCUXpresso combine mcan and ethernet

Jump to solution
631 Views
simon_hilt
Contributor II

Hello,

 

I use the CAN-FD Kit LPCXpresso54618 and its IDE MCUXpresso IDE V11.1.0 This is the first time I use an NXP board.

In my project I want to evaluate the messages of a CAN bus and send them via Ethernet to a measuring laptop.

I can compile and successfully run both communication interfaces in separate projects, but no matter how I merge the configurations of the projects, there will always be some errors or one of the two interfaces will not work.

First I started with the example mcan_interrupt_transfer and changed it a bit so that it communicates with the CAN case from Vector. In CANoe (Vector-Tool) I can send messages, which the NXP board reads and outputs to the console of the IDE.

Next, I took the example project lwip_udpecho_bm and modified it so that when a message arrives, it is sent back with a modified payload. using a packet sender (Packet Sender - Free utility to for sending / receiving of network packets. TCP, UDP, SSL. ) I can now send different packets which are output in the console of the NXP.

Ultimately I need to combine the two interfaces and create a project with a configuration that contains all the required packages and libraries. For this I have tried several steps:


1:    Add the missing packages to the project using the component manager:

pastedImage_8.png

The settings of the two projects are attached in the appendix.

I have to make this correction so that the program can be compiled and executed:

      opt.h:  #define LWIP_ALLOW_MEM_FREE_FROM_OTHER_CONTEXT 1 (0 leads to error:

      "Bare metal requires LWIP_ALLOW_MEM_FREE_FROM_OTHER_CONTEXT=1 because

      pbuf_free() is being called from an ISR")

        From  <https://community.nxp.com/message/1280097> lwIP - MCUXpresso SDK v2.7.0, IDE v11.1

If I now add the CAN packets to the Ethernet project, the program can be executed and the Ethernet interface works, but the CAN port is not active. I get the error message NACK (not acknowledged) in CANoe, so the bus device (the NXP board) is not active.

If I add the Ethernet packets to the CAN project the other way round, the Ethernet cannot be initialized, even if the program is executable. The console then says "Cannot initialize PHY...".

2: So in the next step I tried to create a completely new configuration using the Quickstart panel. But that doesn't work either and leads to the same mistake.

I have tried various additions of packages or variations of the libraries (Redlib, Newlib etc.), but never succeeded.

Do I have to pay attention to anything during configuration or do the two interfaces interfere with each other somehow?

If necessary, I can also upload the projects, but it already fails because of the default settings. I have only combined the two slightly modified examples from the SDK.

Another question: The previous projects are all written in C, but I would like to program in C++ and have tried to implement the example mcan_interrupt_transfer in C++. The NACK error occurred here as well.

A further question is whether I can combine MQTT with CAN, because the example lwip_mqtt_freertos uses the real time operating system Amazon FreeRTOS kernel.  I have only tested this example and did not try to implement it further.

I am very grateful for any help and advice!

Simon

Labels (1)
0 Kudos
1 Solution
403 Views
simon_hilt
Contributor II

Hello nxf46116‌,

I use the Vector CAN interface VN1630a as communication partner to the board for test purposes. In the tool CANoe I have written a small program that allows me to send messages and that outputs all messages from the bus.
When I debug my modified reference example for MCAN on the NXP board, everything works fine. But if I want to run the same project in the configuration with Ethernet, CANoe gives me an error: NACK (not acknowledged). So it detects errors as if there was no bus participant on the line.
It is exactly the same error as if I disconnect the CAN cables from the NXP board and the lines are open.

I wonder why the error occurs, because I only include CAN in the C program and only address CAN, but not Ethernet. There must be something wrong in the configuration of the project, whereby the CAN channel cannot be initialized and causes the error: "kMCAN_BusOffIntFlag".

I have the idea to check all files concerning CAN with those of the reference example and look for changes, like the fsl_phy was changed when adding the CAN packets.

I do not dare to use FreeRTOS before because I have no experience with it. Or would you advise me to start using FreeRTOS?

There are some examples in RTOS that I can quickly get used to. I also had threads and semaphores in my studies, but never programmed them (if I need them at all). I could run Ethernet and CAN in separate threads.

_________

One hour later: First difference in pin_mux.h found: Both files (.h and .c) of the Ethernet configuration are still unchanged after including the CAN.

Added the following in pin_mux.h:
#define IOCON_PIO_FUNC4 0x04u         /*!<@brief Selects pin function 4 */   

       

Added the following in pin_mux.c: Configuration of the pins for CAN according to the reference example:


    const uint32_t port3_pin18_config = (/* Pin is configured as CAN0_TD */
                                         IOCON_PIO_FUNC4 |
                                         /* Selects pull-up function */
                                         IOCON_PIO_MODE_PULLUP |
                                         /* Input function is not inverted */
                                         IOCON_PIO_INV_DI |
                                         /* Enables digital function */
                                         IOCON_PIO_DIGITAL_EN |
                                         /* Input filter disabled */
                                         IOCON_PIO_INPFILT_OFF |
                                         /* Standard mode, output slew rate control is enabled */
                                         IOCON_PIO_SLEW_STANDARD |
                                         /* Open drain is disabled */
                                         IOCON_PIO_OPENDRAIN_DI);
    /* PORT3 PIN18 (coords: M6) is configured as CAN0_TD */
    IOCON_PinMuxSet(IOCON, 3U, 18U, port3_pin18_config);

    const uint32_t port3_pin19_config = (/* Pin is configured as CAN0_RD */
                                         IOCON_PIO_FUNC4 |
                                         /* Selects pull-up function */
                                         IOCON_PIO_MODE_PULLUP |
                                         /* Input function is not inverted */
                                         IOCON_PIO_INV_DI |
                                         /* Enables digital function */
                                         IOCON_PIO_DIGITAL_EN |
                                         /* Input filter disabled */
                                         IOCON_PIO_INPFILT_OFF |
                                         /* Standard mode, output slew rate control is enabled */
                                         IOCON_PIO_SLEW_STANDARD |
                                         /* Open drain is disabled */
                                         IOCON_PIO_OPENDRAIN_DI);
    /* PORT3 PIN19 (coords: J3) is configured as CAN0_RD */
    IOCON_PinMuxSet(IOCON, 3U, 19U, port3_pin19_config);

Now it works! YES! What a relief.

So when adding packages you have to find out given dependencies of files and check them. In my case the pins were simply not configured. But it wasn't shown to me anywhere!

Now I can start FreeRTOS and exclude this error in advance. Thanks for the support!
If I have any questions about FreeRTOS, I will contact you again.

Best Regards,

Simon

View solution in original post

0 Kudos
6 Replies
403 Views
Alexis_A
NXP TechSupport
NXP TechSupport

Hello Simon,

I have some suggestions about this implementation:

Since the ethernet stack implementation is more complex than the CAN module, I would start with one of the ethernet examples and start from there that is your first approach, since the ethernet is a high demanding peripheral if you're using the CAN interruption this could overlap and this could cause the problem.

I will suggest trying using one of the DMA channels not used by the ethernet stack to handle the CAN transfers.

Let me know your findings.

Best Regards,

Alexis Andalon

0 Kudos
403 Views
simon_hilt
Contributor II

Hello Alexis,

Thank you very much for the answer. I will try to fix this memory access error and as soon as I have results, I will let you know.

I have decided to use MQTT. But the reference example is in FreeRTOS, so I try to integrate CAN into this example first and if this is unsuccessful I try to use baremetal without MQTT. But in order to do this, I have to learn the ropes and find out if it's possible. I found this, for example: How to use CAN drivers with FreeRTOS?

But unfortunately I am partly really overwhelmed and work my way in piece by piece.

First of all I talk to the supervisor of my bachelor thesis about how I should proceed, i.e. whether I should stay with baremetal without protocol MQTT or switch to FreeRTOS with MQTT.

If you have any helpful tips, I would be very grateful. (E.g. if and how I have to modify the CAN driver to use it in FreeRTOS or if it is possible to use MQTT in bare metal.)

Best Regards

Simon Hilt

P.S.: Sorry for my bad english...

0 Kudos
403 Views
Alexis_A
NXP TechSupport
NXP TechSupport

Hello Simon,

I would recommend using the RTOS since the administration between the two protocols will be easier but if you don't have previous knowledge would be a little difficult to use.

Best Regards,
Alexis Andalon

0 Kudos
403 Views
simon_hilt
Contributor II

Hello Alexis,

This is also my goal to use FreeRTOS. But if I can't combine the interfaces even without an operating system (in baremetal), it won't work with an operating system either, right?

I debugged the project in baremetal and found out several things:


1) When adding packages there seem to be dependencies, so the fsl_phy files are replaced by older ones where the PHY_Init function is not yet implemented. The function only returns the status "kStatus_Fail". So I manually replaced these two files with the original ones, and lo and behold, Ethernet works again.

2) But CAN still does not initialize itself. I tried to output all registers, but they all seemed to be identical to the project where CAN works. I thought I must be doing something wrong. I then programmed before the while(1) loop that a CAN message would be sent. Then there was a temporary difference due to the output of the status registers in the function "mcan_callback":
The interrupt register had the value 0xa800000. The register is set in the function MCAN_TransferHandleIRQ when the errors "kMCAN_BusOffIntFlag", "kMCAN_ErrorPassiveIntFlag" or "kMCAN_ErrorWarningIntFlag" occur. Then the IR is set to the following errors for a short time:
- "Error_Passive status changed"
- "Bus_Off status changed"
- "Protocol error in arbitration phase detected"

Unfortunately I could not find out where and why these flags are set. The only thing I found is that the IR register is set in this function:

static inline void MCAN_ClearStatusFlag(CAN_Type *base, uint32_t mask)
{
    /* Write 1 to clear status flag. */
    base->IR |= mask;
}

However, this function is only called in two places (in fsl_mcan.c):
In the function "MCAN_TransferHandleIRQ", by setting the above 3 errors to IR.  But this is the consequence of the error I want to find out. It will most likely be the error "kMCAN_BusOffIntFlag".

The second call is in the function "MCAN_TransferReceiveFifoBlocking", but I do not use it.

Where should I focus and start so that I can correct the error? Unfortunately I cannot yet identify the cause.

Best Regards

Simon

0 Kudos
403 Views
Alexis_A
NXP TechSupport
NXP TechSupport

Hello simon.hilt@edag-bfft.com‌,

These errors usually happen when there are transmissions/receptions and the message is not being handled correctly so that let us know that there's some communication on the bus, I would suggest sniffing the CAN lines and check if the transmission is done correctly.

Also, the inclusion of the RTOS could help depending of the error that your software present. Also is important to always use non-blocking operations that not interfere with the ethernet stack.

Best Regards,

Alexis Andalon

0 Kudos
404 Views
simon_hilt
Contributor II

Hello nxf46116‌,

I use the Vector CAN interface VN1630a as communication partner to the board for test purposes. In the tool CANoe I have written a small program that allows me to send messages and that outputs all messages from the bus.
When I debug my modified reference example for MCAN on the NXP board, everything works fine. But if I want to run the same project in the configuration with Ethernet, CANoe gives me an error: NACK (not acknowledged). So it detects errors as if there was no bus participant on the line.
It is exactly the same error as if I disconnect the CAN cables from the NXP board and the lines are open.

I wonder why the error occurs, because I only include CAN in the C program and only address CAN, but not Ethernet. There must be something wrong in the configuration of the project, whereby the CAN channel cannot be initialized and causes the error: "kMCAN_BusOffIntFlag".

I have the idea to check all files concerning CAN with those of the reference example and look for changes, like the fsl_phy was changed when adding the CAN packets.

I do not dare to use FreeRTOS before because I have no experience with it. Or would you advise me to start using FreeRTOS?

There are some examples in RTOS that I can quickly get used to. I also had threads and semaphores in my studies, but never programmed them (if I need them at all). I could run Ethernet and CAN in separate threads.

_________

One hour later: First difference in pin_mux.h found: Both files (.h and .c) of the Ethernet configuration are still unchanged after including the CAN.

Added the following in pin_mux.h:
#define IOCON_PIO_FUNC4 0x04u         /*!<@brief Selects pin function 4 */   

       

Added the following in pin_mux.c: Configuration of the pins for CAN according to the reference example:


    const uint32_t port3_pin18_config = (/* Pin is configured as CAN0_TD */
                                         IOCON_PIO_FUNC4 |
                                         /* Selects pull-up function */
                                         IOCON_PIO_MODE_PULLUP |
                                         /* Input function is not inverted */
                                         IOCON_PIO_INV_DI |
                                         /* Enables digital function */
                                         IOCON_PIO_DIGITAL_EN |
                                         /* Input filter disabled */
                                         IOCON_PIO_INPFILT_OFF |
                                         /* Standard mode, output slew rate control is enabled */
                                         IOCON_PIO_SLEW_STANDARD |
                                         /* Open drain is disabled */
                                         IOCON_PIO_OPENDRAIN_DI);
    /* PORT3 PIN18 (coords: M6) is configured as CAN0_TD */
    IOCON_PinMuxSet(IOCON, 3U, 18U, port3_pin18_config);

    const uint32_t port3_pin19_config = (/* Pin is configured as CAN0_RD */
                                         IOCON_PIO_FUNC4 |
                                         /* Selects pull-up function */
                                         IOCON_PIO_MODE_PULLUP |
                                         /* Input function is not inverted */
                                         IOCON_PIO_INV_DI |
                                         /* Enables digital function */
                                         IOCON_PIO_DIGITAL_EN |
                                         /* Input filter disabled */
                                         IOCON_PIO_INPFILT_OFF |
                                         /* Standard mode, output slew rate control is enabled */
                                         IOCON_PIO_SLEW_STANDARD |
                                         /* Open drain is disabled */
                                         IOCON_PIO_OPENDRAIN_DI);
    /* PORT3 PIN19 (coords: J3) is configured as CAN0_RD */
    IOCON_PinMuxSet(IOCON, 3U, 19U, port3_pin19_config);

Now it works! YES! What a relief.

So when adding packages you have to find out given dependencies of files and check them. In my case the pins were simply not configured. But it wasn't shown to me anywhere!

Now I can start FreeRTOS and exclude this error in advance. Thanks for the support!
If I have any questions about FreeRTOS, I will contact you again.

Best Regards,

Simon

View solution in original post

0 Kudos