• AVR Freaks

Hot!dsPIC33E CAN transmission failure

Author
edga
New Member
  • Total Posts : 19
  • Reward points : 0
  • Joined: 2019/07/10 07:05:25
  • Location: Italy
  • Status: offline
2019/07/25 09:37:22 (permalink)
0

dsPIC33E CAN transmission failure

I am using the dsPIC33EV 5V CAN-LIN STARTER KIT to get acquainted with the use of CAN protocol with dsPIC33E architecture. I tested the Demo Code, given by Microchip, which implements CAN message transmission, with the board connected to a PCAN-USB reader. Everything runs smoothly and I correctly see the CAN packets sent by the board. 
 
I decided then to proceed with the implementation of CAN within one of my project, in which simply the dsPIC reads periodically a sensor through I2C (that part perfectly functioning). The basic version of the project expected the data read through I2C to be transmitted to the PC through UART, the next step I wished to implement was to substitute the UART with a CAN transmission to the PC connected to the PCAN-USB reader. 
 
I implemented CAN and DMA libraries given by MPLABX Code Configurator (yeah, I know, I should avoid it, but so far it worked pretty good for all the rest of functionalities I have implemented), double-checking the consistency and correctness of the APIs with the Microchip reference manuals dedicated to DMA (DS70348C) and CAN (DS70353C), as well as with the Application Note AN1249 (which is the reference followed for development of the Demo Code above mentioned). 
To start with something easy, I simply implemented a single CAN transmission of 8 bytes containing 0x55 each. 
 
Nonetheless, the CAN transmission is not working and inspecting with the debugger I've found out that when the CAN transmission is requested, by setting the flag C1TR01CONbits.TXREQ, it is contextually set also the the flag C1TR01CONbits.TXERR, which indicates that 'a bus error occurred while the message was being sent'. 
 
Generally speaking, which could be the cause generating this error?
I have to ask the question this way because after two days of controlling the code I simply don't know what else I could check. To avoid a cluttered post I avoided on purpose to insert chunks of code but I am available to share specific parts if this could help (e.g. CAN and DMA Init). 
 
Thanks in advance. 
post edited by edga - 2019/07/25 09:40:35
#1
du00000001
Just Some Member
  • Total Posts : 3175
  • Reward points : 0
  • Joined: 2016/05/03 13:52:42
  • Location: Germany
  • Status: online
Re: dsPIC33E CAN transmission failure 2019/07/25 09:47:12 (permalink)
0
Bus error ? Active or passive ? (What's the error counter's value ?)
 
Reasons:
  • No comms "partner" on the bus (PCAN-USB connected?). Thus the transmitter doesn't receive the acknowledgement.
  • Bus lines (CAN-H/CAN-L) erroneously swapped. This results in even greater "issues"...

PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
#2
edga
New Member
  • Total Posts : 19
  • Reward points : 0
  • Joined: 2019/07/10 07:05:25
  • Location: Italy
  • Status: offline
Re: dsPIC33E CAN transmission failure 2019/07/25 10:04:22 (permalink)
0
Thanks for your reply. 
The partner is correctly connected and the lines are not swapped; the proof is given by the fact that the Demo Code works perfectly and I correctly see the packets sent by the board. Also the CAN baud rate is the same (i.e. 250 kbps) as well as the bit time quanta Tq subdivision. 
 
What do you mean with error counter's value? What happens is that TXREQ flag stays stuck at 1 once it is set (and I suppose this is related to the fact that TXERR is raised to 1) and that's it, no transmission on the bus. 
 
Could it be a matter of interrupt priorities (although no other interrupts are enabled in my dummy test)? To be sure, I assigned to CAN1 TX Data Request (IRQ#70) and DMA Channel 0 (IRQ#4) interrupts the highest priorities among all. 
 
PS: Before calling the transmission the interrupts are enabled through:
inline static void INTERRUPT_GlobalEnable(void)
{
    __builtin_enable_interrupts();
}

 
#3
du00000001
Just Some Member
  • Total Posts : 3175
  • Reward points : 0
  • Joined: 2016/05/03 13:52:42
  • Location: Germany
  • Status: online
Re: dsPIC33E CAN transmission failure 2019/07/25 10:17:55 (permalink)
3 (1)
error counter

Each and every CAN controller "somewhere" has a counter to count bus errors. When the error counter (typically) exceeds 127, the controller goes passive (no more transmissions). Not sure whether the error counters are always readable. And it's not expected to be writeable. (Clearing/resetting is often achieved by (re-)initializing the CAN controller.)
 
IF you can see the dsPIC transmitting although the error flag is raised, it's in the "error active" mode. It will take a number of transmissions until the error flag vanishes (when the error counter reaches 0).
 
BTW: are you sure the dsPIC is capable to receive as well? - - - Just in case . . .
 
CAN controllers are somewhat bitches - especially wrt the error recognition and handling.

PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
#4
edga
New Member
  • Total Posts : 19
  • Reward points : 0
  • Joined: 2019/07/10 07:05:25
  • Location: Italy
  • Status: offline
Re: dsPIC33E CAN transmission failure 2019/07/25 10:44:31 (permalink)
0
Error counter check done (thank you for the hint). 
I printed through UART the value of the Transmit Error Counter (CiEC<15:8>) within the following loop (which is infinite since the transmission request flag TXREQ is never cleared): 
while (C1TR01CONbits.TXREQ0 == 1)

and it appears that it constantly rolls from 0 to 255, never stopping. 
 
Yes, I am sure the dsPIC is capable to receive, the manuals state this as well as the Demo Code which implement also CAN receiving features. 
#5
du00000001
Just Some Member
  • Total Posts : 3175
  • Reward points : 0
  • Joined: 2016/05/03 13:52:42
  • Location: Germany
  • Status: online
Re: dsPIC33E CAN transmission failure 2019/07/25 11:09:11 (permalink)
0
Oh, it's clear that the dsPIC is basically capable to receive.
The question was more whether your current hardware/software setup is capable of this.
(CAN transceiver operational and correctly attached, signals routed correctly on-chip etc. pp.)
 
From my understanding, rolling over should never occur without some reinitialization interaction...

PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
#6
edga
New Member
  • Total Posts : 19
  • Reward points : 0
  • Joined: 2019/07/10 07:05:25
  • Location: Italy
  • Status: offline
Re: dsPIC33E CAN transmission failure 2019/07/26 00:10:14 (permalink)
0
Since the HW involved is basically only the Microchip Eval Board connected to the CAN reader, I would say it is all okay (although I have not tried to receive any packets yet).
 
As you correctly stated, mentioning the dsPIC33E CAN Reference Manual:
When the Transmit Error Counter exceeds a value of 255, the node enters the Bus OFF state. [...] A node that is in the Bus OFF state transmits nothing on the bus.

 
Something is wrong with my CAN/DMA configuration and I cannot find it; I decided to adopt a Bottom -> Top approach, that is I will start a blank project in which include the CAN transmission only. Once I get it working properly, I'll try to add all the other features I'm interested in. 
This way I hope it'll be more clear and evident whether there are some conflicts among peripherals/interrupts. 
#7
edga
New Member
  • Total Posts : 19
  • Reward points : 0
  • Joined: 2019/07/10 07:05:25
  • Location: Italy
  • Status: offline
Re: dsPIC33E CAN transmission failure 2019/07/26 02:24:31 (permalink)
0
UPDATE#1
I set up a bare project containing only the necessary to make the CAN functioning. MCC libraries used. 
As soon as the tx request is set, the ECAN Event Interrupt is set, with the following flags set inside the C1INTF (CAN1 INTERRUPT FLAG REGISTER):
  • TXB0 - Transmitter in Error State Bus Off bit (which causes consequently ERRIF - Error Interrupt Flag set)
  • IVRIF - Invalid Message Interrupt Flag bit
I have never checked to content of C1INTF before, but I am pretty sure I would find the same error flags. 
I think I'll try to implement a bare CAN project avoiding MCC, otherwise I don't know what to do. 
#8
du00000001
Just Some Member
  • Total Posts : 3175
  • Reward points : 0
  • Joined: 2016/05/03 13:52:42
  • Location: Germany
  • Status: online
Re: dsPIC33E CAN transmission failure 2019/07/26 02:31:42 (permalink)
0
"invalid message"  ??
 
Which board/derivative do you use?

PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
#9
edga
New Member
  • Total Posts : 19
  • Reward points : 0
  • Joined: 2019/07/10 07:05:25
  • Location: Italy
  • Status: offline
Re: dsPIC33E CAN transmission failure 2019/07/26 02:49:49 (permalink)
#10
du00000001
Just Some Member
  • Total Posts : 3175
  • Reward points : 0
  • Joined: 2016/05/03 13:52:42
  • Location: Germany
  • Status: online
Re: dsPIC33E CAN transmission failure 2019/07/26 06:44:48 (permalink)
0
OK, with the EV I'd try to start with the code that comes with the board, gradually extending it.
(I have to tell that I'm using this board too - but until now never used the CAN. There are other aspects of this board that attracted me...)

PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
#11
edga
New Member
  • Total Posts : 19
  • Reward points : 0
  • Joined: 2019/07/10 07:05:25
  • Location: Italy
  • Status: offline
Re: dsPIC33E CAN transmission failure 2019/07/26 07:08:09 (permalink)
0
du00000001, thanks again for your answers. 
 
I've already thought about what you suggest and then in my (newbie) mind a doubt arose: since I have all the features I desire working correctly with MCC APIs, may I create a "hybrid" code with everything set with MCC except CAN and DMA? Are there any risks related to this? 
For example, by doing this I would lost the correct mapping on used pins in the MCC Pin Manager view (I have already checked this). 
 
In the meanwhile...
UPDATE#2
I found out the MCC dsPIC33 library was not updated to the latest version (1.95), I was still using v1.125. In the dummy project, the one with only the CAN feature implemented, I downloaded the latest library and re-tested. This time, no error flags are set but the TXREQ is never cleared. I'll try to understand which parts of the library changed. 
 
 
 
#12
du00000001
Just Some Member
  • Total Posts : 3175
  • Reward points : 0
  • Joined: 2016/05/03 13:52:42
  • Location: Germany
  • Status: online
Re: dsPIC33E CAN transmission failure 2019/07/26 07:34:54 (permalink)
0
Noone forces you to really use the code MCC provides.
So you could go with the pin mapping of MCC while using your own CAN code (including CAN setup beyond mere pin mapping).
 
TXREQ ... never cleared

Could be a feature (provided the actual TX is triggered by a 0->1 transistion), could be a bug. Or MCC relies on you using some TX interrupt to clear this flag.
With some luck you'll be able to find some documentation (aka source code comment in case of MCC) on the expectations.

PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
#13
edga
New Member
  • Total Posts : 19
  • Reward points : 0
  • Joined: 2019/07/10 07:05:25
  • Location: Italy
  • Status: offline
Re: dsPIC33E CAN transmission failure 2019/08/08 01:37:27 (permalink)
0
I have finally found the solution.
 
Shortly, within the dsPIC33EV 5V CAN-LIN STARTER KIT the dsPIC controls the MCP2561 CAN Transceiver standby pin with its RG9 pin.
Therefore, what I needed was just to initialise that pin and set it LOW, so that the CAN Transceiver is able to work in Normal Mode. 
 
The MCC libraries are all right, I guess the only flaw in all this scenario is the fact that within the User Guide of the Evaluation Board is not written explicitly anywhere about this Standby pin of the Transceiver. 
I've found out about it by analysing better both the schematic (pag.32 of the EV User Guide) and the Demo code provided by Microchip (in particular lines 1088 and 1089).
 
Thank you du00000001, you gave the prompts to analyse and understand better the dsPIC33 architecture. 
#14
Jump to:
© 2019 APG vNext Commercial Version 4.5