Basic CAN sniffer/monitor

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Basic CAN sniffer/monitor

952 Views
gwen_stouthuyse
Contributor I

nxf46116 

Could you help me out creating a small example program to digest CAN 2.0B (Extended 29b address range) messages to simply list them on the serial terminal. using FRDM-KW36

How to activate/deactivate acknowledgements?

I have the idea my messages come too fast, 4 messages in less than 3msec, which corrupts somehow the receiver circuitry/code.

Somehow I have to learn how NXP addresses these aspects.

I'm not a formal µC programmer but an application development engineer and I would like to create a POC to showcase an alternative approach to a problem.

I'm close to stop using the NXP solution, but I can't believe NXP is not able to handle these CAN applications. 

0 Kudos
5 Replies

831 Views
gwen_stouthuyse
Contributor I

joschka.traupe@silab.de 

The problem is not the messages: they are present anyway.

The speed is 250k, so a transmission takes 512 usec.

A normal transmission (captured with pcan-view) looks like this:

; Message Number
; | Time Offset (ms)
; | | Type
; | | | ID (hex)
; | | | | Data Length
; | | | | | Data Bytes (hex) ...
; | | | | | |
;---+-- ----+---- --+-- ----+--- + -+ -- -- -- -- -- -- --
1) 14867.2 Rx 1CFD083F 8 6B 18 2F 67 95 4C FF FF
2) 14867.8 Rx 18FEEE3F 8 FF FF 3C 25 FF FF FF FF
3) 14868.4 Rx 18FF313F 8 00 FF FF FF FF FF FF FF
4) 14869.0 Rx 18FFFF3F 8 54 67 00 00 FF FF FF FF
5) 46326.7 Rx 1CFD083F 8 6B 18 2F 67 95 4C FF FF
6) 46327.3 Rx 18FEEE3F 8 FF FF 3C 25 FF FF FF FF
7) 46327.9 Rx 18FF313F 8 00 FF FF FF FF FF FF FF

The problem is that while processing a message, the next interrupt is to be fired due the next message is in, where I think something goes wrong.

0 Kudos

831 Views
Alexis_A
NXP TechSupport
NXP TechSupport

Hello Gwen,

If the problem is the reception and that you don't have enough time to process the message burst it will be better to use the FIFO to receive the messages or if you don't want to configure it, also you can use the DMA to handle the transmission without the CPU intervention.

For the second there's an example loopback_edma_transfer that you can take a look.

Let me know if this helps you.

Best Regards,

Alexis Andalon

0 Kudos

831 Views
gwen_stouthuyse
Contributor I

Alexis,

I followed the advice and reworked the loopback_edma_transfer example to receive my messages.

I had to set the right message ID's in the fifo filter configuration:

uint32_t rxFifoFilter[] = { FLEXCAN_RX_FIFO_EXT_FILTER_TYPE_A(0x1cfd083f, 0, 0), FLEXCAN_RX_FIFO_EXT_FILTER_TYPE_A(0x18FEEE3F, 0, 0), FLEXCAN_RX_FIFO_EXT_FILTER_TYPE_A(0x18FF313F, 0, 0), FLEXCAN_RX_FIFO_EXT_FILTER_TYPE_A(0x18FFFF3F, 0, 0)};

(Next to adapting some more lines in the code to couple the CAN circuitry to the pins, this made it working)

How can to receive every message ID?

Next to the success I notice not everything works as it should do: the second message doesn't get acknowledged the first time is is send out.

The sensor has to repeat it. 

Thanks,

Gwen

0 Kudos

831 Views
Alexis_A
NXP TechSupport
NXP TechSupport

Hello Gwen,

As you're declaring the FIFO matching ID table looks good but in the FLEXCAN_RX_FIFO_EXT_FILTER_TYPE_A API the last field mentions the IDE bit. I see that you're using an extended frame si the IDE should be 1:

pastedImage_1.png

Best Regards,

Alexis Andalon

0 Kudos

831 Views
joschka_traupe
Contributor I

in my mind the message speed are ok. 

For example when you use a 1MBit CAN-BUS Speed 1bit needs 1us -> a whole Frame with 8bytes of data needs 128bits (exclusiv bitstuffing)-> the whole frame needs 128us for transmission.

0 Kudos