• AVR Freaks

Hot!MCC configurated ECAN module - cannot trasmit() a single frame sucessfully

Author
GMWood
New Member
  • Total Posts : 6
  • Reward points : 0
  • Joined: 2019/09/09 06:01:40
  • Location: Sofia, Bulgaria
  • Status: offline
2019/09/10 08:05:31 (permalink)
0

MCC configurated ECAN module - cannot trasmit() a single frame sucessfully

MCC configurated ECAN module - cannot trasmit() a single frame sucessfully
 
Greetings Gents,
 
This is my first post here in the forum, so let’s see what will come of it :)

I’ve been trying to create and run some simple code example for the CAN peripheral of a PIC18F, utilizing the MCC tool to generate the necessary initial code and abstracted functions for further use. The example is supposed to be simple as possible – the PIC18 is attempting to transmit over the CAN bus  a single frame in an endless loop, with some delay between the transmit instances. To which, two other devices (USB-CAN analyzers: one of which is http://www.icpdas.com/roo...erter/i-7565-h1h2.html
and the other one is:
https://www.seeedstudio.c...r-p-2888.html#reviews) are connected to and just listening to.
The code is written in a way that each time a message is successfully queued for transmission (though not necessarily send), both LEDs (H1 & H2) below will turn on, or if not they will turn off.

Here’s partial schematic of the HW configuration around the PIC18F25K80 side :
 
PPA_PICschematic_partial.PNG
 
Here’s how the CAN transceiver (driver) circuit for the PIC18 had been realized:
 
 PPA_CANdriver_schematic.PNG
 
The CAN bus (the points where the other CAN enabled devices are hooked up to) are the “CAN_L” and “CAN_H” signals/points. Think of them as pins of a 2-pin terminal block. The other two devices have their own (built-in internal) terminating (120 Ohms) resistors present among their respective CAN_L and CAN_H pins, so there is no need to put a terminating resistor here on the PIC18 tranceiver side.

The issue:

In this HW bus entanglement both USB-CAN analyzers can talk to each other without any problems. They can pick and send each others messages – no problems there. The problem is, when PIC18 tries to send any frame away, neither of the analyzers detect/see any message coming from the PIC18 side. It’s like there hasn’t even been an attempt at sending anything on the CAN bus from the PIC18 side. Every single device in this chain is set to 125 kbit/s.

When trying to debug the code with an ICD4 , going in a step-by-step fashion and looking how the code is executed, I observe that each time the CAN_transmit(uCAN_MSG *tempCanMsg) function is executed. A dedicated transmit buffer registers is first checked (its TXREQ bit), then if its clear, its adjacent data buffers are filled with appropriate data and then it is set to transmit (TXREQ is set to 1). But after the TXREQ bit is set for its asociated transmit buffer, it never gets cleared (automatically) after a while (as it is supposed to when successfully transmitting a frame.) So the next time CAN_transmit() is called, the next in line buffer (TXB1.. or TXB2.. ) gets uploaded with data and set transmit (their TXREQ bits are set to 1). But again, those bits do not get cleared.  
After that all the buffers are filled and not freed, so the next time the CAN_transmit() function is called, just returns immediately, and the LEDS turn off. 
During all this there's no activity on the bus.

So the end result is, when the board (featuring the PIC18) is powered on, after some initial delay, the LEDs turn on for a while (in the first 3 times the CAN_transmit() is called in the while loop), and then they are turned off and remain off.
 
So my question is, what is going on and how can I fix this? What is the source of this problem, after all I am using the MCC as foundation here?
 
Some other parameters of my HW/SW development setup:
PIC18F25K80 – Device Revision Id = 0x6
MPLAB X IDE: v5.20
MCC: v3.85.1
XC8: 2.10 (Free version, code is set to not be optimized – 0 , with ‘Debug’ option checked)
Debugger/Programmer used: ICD4
 
The full project is attached as: MP1_CAN_MCC_v2p10_ex3.X.zip
 
Anyway, I am somewhat new to the PIC environment and devices, so any insight, advice or helpful information is
welcome. If you have further suggestions about something to try and give back feedback, please feel
free to do so.

Thank you & Best Regards,
GMWood
 

Attached Image(s)

#1

13 Replies Related Threads

    du00000001
    Just Some Member
    • Total Posts : 3946
    • Reward points : 0
    • Joined: 2016/05/03 13:52:42
    • Location: Germany
    • Status: online
    Re: MCC configurated ECAN module - cannot trasmit() a single frame sucessfully 2019/09/10 09:38:16 (permalink)
    0
    Some questions:
    1. The CAN analyzers are still able to communicate when the PIC18 is attached to the bus, powered and "under steam" ?
    2. Did you check the PIC18's CAN TX line for activity?
    3. The same for the CAN RX line when the analyzers are talking to each other?
    The above measurements to be made with an oscilloscope or - maybe - a logic analyzer.
     
    Comments:
    • Not sure about the capacitive loading of the CAN bus with all these caps and the Transzorbs. Might be too much. (Check #1 is intended to target this.)
    • Are you sure you've configured the CAN TX pin as a digital output and the CAN RX pin as a digital input ?
      And that you have routed the CAN signals to the resp. pins ?

    PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
    #2
    GMWood
    New Member
    • Total Posts : 6
    • Reward points : 0
    • Joined: 2019/09/09 06:01:40
    • Location: Sofia, Bulgaria
    • Status: offline
    Re: MCC configurated ECAN module - cannot trasmit() a single frame sucessfully 2019/09/11 00:39:23 (permalink)
    0
    Hello du00000001 and all,
     
    Regarding your Qs:
     
    1. Yes, both USB-CAN analyzers are able to communicate with each other, exchange frames amongst themselves, when the board featuring PIC18F is powered on (I guess this is what you mean "under stream"). To further elaborate on some, I start to exchange messages between the analyzers after both the H1 and H2 leds turn off (indicating that that the PIC18F stopped successfully queuing messages in the loop - I've attached my project , you can check how the code works).
     
    2. Yes I did, here's an explanation of my test:
    I've used a logical analyzer (DSLogic Plus) to observe the CAN_RX , CAN_TX and CAN_L lines of the bus,  the active (Red) probes connected to those signals. The ground (Black) probes connected to GND of the board. I've taken a DSView data dump while doing the following: 
    i.) The board/device featuring the PIC18F is turned OFF. 
    ii.) I start the logical analyzer program (DSView) and initiate a recording of data for 5 sec.
    iii.) After 1 - 1.5 seconds, I power ON the board. (During this time the PIC should be attempting to send the CAN data)
    iv.) I wait till the recording period finishes and the take and store logic dump.
    I've attached the recorded dump in the "DSView_CAN_lines_dump.zip". You can check with what configuration was used for DSView in the attached pics ( "DSView_Settings1of2.PNG" and "DSView_Settings2of2.PNG")
    Overall, in my view, I don't see any coherent/proper activity on any of the lines - just some jitter that does not make any sense. 
     
    3. I'll come back later on this point, record a logic dump and attach it to a new post. We can discuss further.
     
     
    Regarding the comments, on the 2nd an 3rd bullet points:
    • I've used the MCC to configure the pins, the clock and ECAN module (I don't use interrupts) as it is supposed to. This is why I am baffled so much, because I don't really use my own code, but something (API) that comes officially from Microchip that is supposed work out of the box. You can check the attached project and see everything for yourself. (also I reached the upload limit for this post, I'll post screen caps in a following response)
     
    Thank you so much for you help,
    GMWood

    Attached Image(s)

    #3
    GMWood
    New Member
    • Total Posts : 6
    • Reward points : 0
    • Joined: 2019/09/09 06:01:40
    • Location: Sofia, Bulgaria
    • Status: offline
    Re: MCC configurated ECAN module - cannot trasmit() a single frame sucessfully 2019/09/11 00:45:45 (permalink)
    0
    Just a follow-up,
    Attached are the screen caps of the MCC settings used for the program/issue described in the previous posts.
     
    Cheers,
    GMWood
     
     
     

    Attached Image(s)

    #4
    du00000001
    Just Some Member
    • Total Posts : 3946
    • Reward points : 0
    • Joined: 2016/05/03 13:52:42
    • Location: Germany
    • Status: online
    Re: MCC configurated ECAN module - cannot trasmit() a single frame sucessfully 2019/09/11 01:32:38 (permalink)
    0
    Some comments:
    • Even MCC-generated code requires proper integration and calls.
    • I currently do not have time to check whether I would be able to open .dsl files - meaningful plots are ok. And I do not want to "discuss" either.
    • "Under steam" means "powered and SW running (whatever the SW is doing).
     
    1. I want to see the RX signal "under steam" while the analyzers (!) are exchanging messages ! (to assert a number of things)
    2. #1 before the lights go off! (Once the PIC18 stopped attempting to TX, there's little useful to gain.)
    3. ...

    PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
    #5
    GMWood
    New Member
    • Total Posts : 6
    • Reward points : 0
    • Joined: 2019/09/09 06:01:40
    • Location: Sofia, Bulgaria
    • Status: offline
    Re: MCC configurated ECAN module - cannot trasmit() a single frame sucessfully 2019/09/11 07:07:52 (permalink)
    0
    Hi again du00000001, 
     
    Thank you for the quick reply. 
    Regarding to your comments:
     
    • The MCC in my case, had been configured following the AN2714 as closely as possible and adjusting it to my HW setup. Once the MCC is configured through the GUI and the code is generated. The only necessary thing you have to do is call ECAN_Initialize() (which is called in the SYSTEM_Initialize(); function) and then call the CAN_transmit() if you want to transmit. That's at least how I understand it. Attached is the code that is in the main.c file and is the only code/file that I have edited for my project. The rest of the files in the project are left as per MCC created them. 
     
    So I don't know for this simple case what additional integration or calls I need to do, if someone knows, please post your feedback. 
     
    Btw, in the MCC configuration, I experimented changing the following:
     - Enabled  CAN_TX pin to "Start High' tick (in Pin Module)
     - Enabled 'Enable CAN Bus Activity Wake-up' tick (in ECAN)
    The result:
     Situation is the same as before - no activity on the CAN_TX line.
     
    • Regarding the signal plots, the .dsl files can be opened with the DSView program which is free. I suggest using it as it is going to give the biggest and best scope (resolution) of the entire 5 sec period down to (40 nsec granularity). Otherwise, I've tried to depict the signal levels when powering up the board in different scopes (attached zip with png files )
     
    Later today, I will share signal plots while both CAN analyzers are exchanging info, and simultaneously with that the PIC18F also trying to send its own data.
     
     PS. Why do I always get "Access Denied" when attempting to submit a post with attachments, or something else??? It's so annoying it's beyond belief.
    post edited by GMWood - 2019/09/11 07:10:08
    #6
    du00000001
    Just Some Member
    • Total Posts : 3946
    • Reward points : 0
    • Joined: 2016/05/03 13:52:42
    • Location: Germany
    • Status: online
    Re: MCC configurated ECAN module - cannot trasmit() a single frame sucessfully 2019/09/11 08:24:53 (permalink)
    0
    What else you have to configure the right way? E.g. the pins!
    • One of the plots shows activity on CAN (CAN_L), but not on CAN_RX. This is just impossible if everything were configured correctly. (CAN transceivers are comparably dumb devices.)
    • If CAN_RX doesn't reflect the state of CAN_L (which it doesn't on your board), the CAN controller will not make more than a single (or maybe a small number of) attempt(s) to access the bus.
    So maybe you have to get your hardware right before proceeding...

    PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
    #7
    GMWood
    New Member
    • Total Posts : 6
    • Reward points : 0
    • Joined: 2019/09/09 06:01:40
    • Location: Sofia, Bulgaria
    • Status: offline
    Re: MCC configurated ECAN module - cannot trasmit() a single frame sucessfully 2019/09/11 12:05:52 (permalink)
    0
    Hi, 
     
    My assumption is that the pins are  need to configured only during the MCC configuration phase (using the GUI via its check boxes, and other menus.) utilizing the MCC application to set all those neccesary components - see the attached pics of comment #4 . I presume that this is (look at the Pin Manager: Grid View window and the Pin Module tab window) correct for my case. I don't think I need to do anything more (program them myself additionally) later on regarding the pin states, etc. That's all settled by the MCC.
     
    Referring to the CAN_L and CAN_RX discrepancy in activity. Here my suspicion is due to possible floating voltages
    Let me say that two USB-CAN analyzers have only their CAN_L and CAN_H pins (cables) connected to each other and the PIC18F board. There is no common (no sharing of) GND between them and/or PIC18F board's GND.
    The USB Logical Analyzer uses the PIC18F's board GND as reference and 'measures' the CAN_TX, CAN_RX and CAN_L in respect to that. Also it uses a voltage threshold of 2.0V. So, my assumption here is that the CAN_RX and CAN_TX are more stable and "grounded", because they 'really' refer to the PIC18F's board GND, while the CAN_L can be more "floating" and susceptible to deviations or offset in some manner. Thus it triggers more 'easily' and 'frequently' the Logical analyzer 2.0V threshold for detecting something as high. But I could be totally in the wrong here.
    I  am really not that experienced in CAN. These are my first steps.
     
    On the request to show plots of CAN activity while the PIC18F device is "under stream" while the USB-CAN analyzers are sending messages to each other. Here's a plot of the activity. Basically what I did here was similar to the previous cases:
    1. Start capture while the board is OFF.
    2. A second after power ON the board.
    3. Immediately after powering the board, start to manually send CAN frames via one of the USB-CAN analyzer's SW tools, trying to click "Send Message" as soon and as quickly as possible. Basically the first messages were sent while the Leds of the PIC18F were still on.
    4. Do this till the 5 sec recording finishes out.
     
    Now, the message that the USB-CAN analyzer was sending had this structure:
    Mode: Normal Mode, Type: Standard Frame , CAN bps: 125 kbit/s
    ID: 0x123 Format: Data frame DLC: 8 ; Data0:0x11 Data1:0x22 Data2:0x33 Data3:0x44 Data4:0x55 Data5:0x66 Data6: 0x77 Data7: 0x88
    A complete picture can be obtained from .dsl file in the .zip
    Overall the send frames by analyzer are manifested in the CAN_RX line I think correctly.
     
    Cheers,
    GMWood
     
     
     
     
     
     

    Attached Image(s)

    #8
    du00000001
    Just Some Member
    • Total Posts : 3946
    • Reward points : 0
    • Joined: 2016/05/03 13:52:42
    • Location: Germany
    • Status: online
    Re: MCC configurated ECAN module - cannot trasmit() a single frame sucessfully 2019/09/11 12:25:06 (permalink)
    0
    This is the first time I see your CAN_RX active/receiving something !
    (CAN_L and CAN-RX are expected to show the same waveforms, although not the same voltage levels.)
     
    CAN is made to cope with (somewhat) floating grounds. If resp. contacts are available, connecting all grounds might somewhat improve bus performance, provided the individual supplies are isolated vs. each other previously.
     
    Now that the CAN_RX seems to be operational, you might re-try to transmit. Or maybe first check whether your PIC is capable to receive the message(s) from the analyzer.
     
    For convenience: check whether you can convince the analyzer to transmit periodically - e.g. every 100 ms.

    PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
    #9
    GMWood
    New Member
    • Total Posts : 6
    • Reward points : 0
    • Joined: 2019/09/09 06:01:40
    • Location: Sofia, Bulgaria
    • Status: offline
    Re: MCC configurated ECAN module - cannot trasmit() a single frame sucessfully 2019/10/08 03:06:06 (permalink)
    0
    Greetings all,
     
    Thank for all the feedback so far. I've managed to track down the issue why there was no activity on the CAN lines when trying to transmit a frame. The issue is HW related - specifically, the schematic I posted in my original post does not reflect the real connections between the MCU's CAN periphery and the associated tranceiver. In turns out, the MCU's CAN_TX is wired to the Tranceiver's RXD (R) pin, and the MCU's CAN_RX pin is wired to the Tranceiver's TXD (D).

     
    Which is completely wrong.
     
    So, bottom line, I assume all the problems I've shown so far are related to this HW mistake.
     
    But anyway, my problems are still not resolved. 
    Now, I've taken another version of the board that has the CAN pinning and connections done correctly - checked. I have tried to upload my code to it again, but again when trying to transmit a frame, CAN bus errors are being detected by the USB-CAN analyzer. 
    I will elaborate more in a following post. So please do not close this topic. I'll write back soon.
     
    Best Regards,
    GMWood
     
     

    Attached Image(s)

    #10
    RobDwi
    New Member
    • Total Posts : 9
    • Reward points : 0
    • Joined: 2020/01/22 04:31:03
    • Location: 0
    • Status: offline
    Re: MCC configurated ECAN module - cannot trasmit() a single frame sucessfully 2020/08/06 20:45:45 (permalink)
    0
    I am brand new to this forum,
    Hi I am brand new to this forum.
    Have moved this thread to "Multi-node eCan errors "
    post edited by RobDwi - 2020/08/08 00:45:24

    Attached Image(s)

    #11
    du00000001
    Just Some Member
    • Total Posts : 3946
    • Reward points : 0
    • Joined: 2016/05/03 13:52:42
    • Location: Germany
    • Status: online
    Re: MCC configurated ECAN module - cannot trasmit() a single frame sucessfully 2020/08/07 10:42:29 (permalink)
    0
    @ RobDwi
    Don't seize existing treads - start your own !

    PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
    #12
    RobDwi
    New Member
    • Total Posts : 9
    • Reward points : 0
    • Joined: 2020/01/22 04:31:03
    • Location: 0
    • Status: offline
    Re: MCC configurated ECAN module - cannot trasmit() a single frame sucessfully 2020/08/08 00:00:10 (permalink)
    0
    Hello dhoooooooo1,
    I haven't been to many forums, I just found a topic that was similar to my problem, But after going through a few of these microchip forums they are all set up to solve a particular problem, I just tried to open a new thread but got asked in dialog to open a popup ?, I like everyone else I know absolutely hate popups and they want me to make one.
    so I went looking for the forum procedures listing, haven't found them yet. Thanks for the heads up du000000001.
    #13
    du00000001
    Just Some Member
    • Total Posts : 3946
    • Reward points : 0
    • Joined: 2016/05/03 13:52:42
    • Location: Germany
    • Status: online
    Re: MCC configurated ECAN module - cannot trasmit() a single frame sucessfully 2020/08/08 02:20:47 (permalink)
    0
    Simply click "Post new thread" - no need to select "Popup Style".
    But maybe you should get new acquaintances - from time to time a popup might make sense.

    PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
    #14
    Jump to:
    © 2020 APG vNext Commercial Version 4.5