topic Re: lpc11c24 can problems in LPCXpresso IDE

lpc11c24 can problems

lpcware — Wed, 15 Jun 2016 22:53:43 GMT

Content originally posted in LPCWare by gtt_rik on Mon Nov 17 07:38:59 MST 2014
Hello,

I have an issue with the ccan functionality on the LPC11c24 microcontroller on the lpcxpresso board.
It seems that it has been configured correctly to transmit but i cannot be sure.

After setting up, it correctly sends the can message, but instead of just doing it once, it keeps sending the message.
Also, it does not trigger the callback function.
Is this because the message needs to be acknowledged by other nodes in the network?

A can-analyzer is available but it does not seem to work (termination?), but the message contents have been confirmed with an oscilloscope.
Added below are the source files

Yours sincerely,

Rik Freije
Electrical Engineer power train
Green Team Twente

Main.c
http://pastebin.com/uDfJ9VSw
ccanlib.c
http://pastebin.com/pL4Fsm3Y
ccanlib header
http://pastebin.com/VD2x9HxM

Re: lpc11c24 can problems

lpcware — Wed, 15 Jun 2016 22:53:44 GMT

Content originally posted in LPCWare by MikeSimmonds on Mon Nov 17 08:05:19 MST 2014
A CAN transmission is not deemed sucessfull unless another node (any other node) ACKnowledges the packet frame.
The CAN controller will re-transmit at intervals indefinately until it gets an acknowlegement.

Your CAN analyser is most probably is LISTEN mode. I detects and displays all messages on the CAN bus, but
DOESN'T acknowledge anything.

Your setup is probably correct, you just need another active CAN node on the bus. Do you have two prototypes.

You seem less than familliar with CAN operation. Try googling CAN BUS or see the Wikipedia page for CAN Bus.

HTH, Mike

PS Double posting will not win you any friends.

Re: lpc11c24 can problems

lpcware — Wed, 15 Jun 2016 22:53:45 GMT

Content originally posted in LPCWare by R2D2 on Mon Nov 17 08:45:40 MST 2014

Quote: gtt_rik
Is this because the message needs to be acknowledged by other nodes in the network?

Yes, to avoid this just set DAR (Disable automatic retransmission) in CANCNTL register :)

Re: lpc11c24 can problems

lpcware — Wed, 15 Jun 2016 22:53:45 GMT

Content originally posted in LPCWare by BoiOkkenGTT on Mon Nov 17 09:05:40 MST 2014
Hello, i am working together with Rik on the same system.

Quote: MikeSimmonds
A CAN transmission is not deemed sucessfull unless another node (any other node) ACKnowledges the packet frame.
The CAN controller will re-transmit at intervals indefinately until it gets an acknowlegement.

Your CAN analyser is most probably is LISTEN mode. I detects and displays all messages on the CAN bus, but
DOESN'T acknowledge anything.

This is strange since we put the CAN analyzer explicitly in normal mode and the can analyzer does not detect or display anything. This is why i suspected the termination to be wrong, but after looking over both the documentation for the lpcxpresso board and the can analyzer, it seems to be terminated properly.
We also did not know that the hardware of the 11c24 defaults to automatic retransmission.
I will go over the settings again tommorow to verify that the can analyzer is actually set up correctly. BTW, the analyzer used is the one from microchip.

Quote: MikeSimmonds

Your setup is probably correct, you just need another active CAN node on the bus. Do you have two prototypes.

We do have more than one board, but using the analyzer is more convienient for quick debugging etc.

Quote: R2D2

Quote: gtt_rik
Is this because the message needs to be acknowledged by other nodes in the network?

Yes, to avoid this just set DAR (Disable automatic retransmission) in CANCNTL register :)

Ah, i will look over that option tommorow.

Thank you both very much.

Yours sincerely,
Boi Okken

Electrical Engineer
Drive train and secondary systems
Green Team Twente

Re: lpc11c24 can problems

lpcware — Wed, 15 Jun 2016 22:53:46 GMT

Content originally posted in LPCWare by BoiOkkenGTT on Wed Nov 19 04:19:30 MST 2014

Quote: BoiOkkenGTT

This is strange since we put the CAN analyzer explicitly in normal mode and the can analyzer does not detect or display anything.
...
I will go over the settings again tommorow to verify that the can analyzer is actually set up correctly. BTW, the analyzer used is the one from microchip.

After working on it yesterday and today, i think the problem indeed lies with the can bus analyzer.

Quote: BoiOkkenGTT

We do have more than one board, but using the analyzer is more convienient for quick debugging etc.

We used a second board to receive messages from the first board, which works. Also confirmed with the oscilloscope that only one single message is send and no retransmission occurs.

I think the topic can be closed, once again thank you for your help.

Yours sincerely,
Boi Okken

Electrical Engineer
Drive train and secondary systems
Green Team Twente

Re: lpc11c24 can problems

lpcware — Wed, 15 Jun 2016 22:53:46 GMT

Content originally posted in LPCWare by R2D2 on Wed Nov 19 05:32:21 MST 2014

Quote: BoiOkkenGTT
Also confirmed with the oscilloscope that only one single message is send and no retransmission occurs.

Your oscilloscope can also show you if there's an ACK in the ACK slot of the frame...

Re: lpc11c24 can problems

lpcware — Wed, 15 Jun 2016 22:53:47 GMT

Content originally posted in LPCWare by MikeSimmonds on Wed Nov 19 07:37:52 MST 2014
I had an issue with my CAN setup early on. Scope showed apparently good signals
sometimes receive, Analyzer would never ack.

Turned out all those sync/propogation/phase1/phase2 and sync jump width in the Bosch spec
mapping to tseg1 and tseg2 in the LPC interface and the minus-one encoding in the LPC registers
meant that although my actual bit rate was right, the 'segments' added up to one more than
they should. Hence progressive bit sample time shifting. And explained short messages
with lots of 1-0-1 changes in the pattern were mostly ok, longer payloads/runs of 1 or 0 not.

Two (wrongly programmed) custom boards would probably be ok. You need to talk to a foreign
device (you analyser) to confirm spec complience.

I use the 1778 so the register name may be different and rearranged (don't have time to read the 11xxx manual.
Also, I write my 'drivers' in M3 assembler. But at least the commentary, macros (#defines) in the following
snippet should help you double check you bit rate setup.

HTH Mike

;-----------------------------------------------------------------------!
; Init CAN Module [2]!
;-----------------------------------------------------------------------!

;  P0.4  CAN 2 Rx !pu/d !hys !inv !filter fast slew !OD
;  P0.5  CAN 2 Tx !pu/d !hys !inv !filter fast slew !OD
;  P1.12 CAN Stby  pu   !hys !inv !filter fast slew !OD output


P112= (1<<28)+(12<<20)+(1<<12)+0x01; P1.12[1] out/lo

Clk= 120000000; peripheral clock = 120MHz
;CBT=    250000; can bit rate = 250Kbps
CBT=   1000000; can bit rate =   1Mbps
TQ=        24; nbr time quanta per bit

BPR= ((Clk/CBT)/TQ)-1; baud 250Kbps [24 quanta per bit]

; Sync+Prop+Phase1+Phase2 MUST EQUAL TQ; and all must be <= 8

Sync= 1; sync = 1 [Mandated by spec]
Prop= 7; propagation delay
Phase1= 8; pre  sample point
Phase2= 8; post sample point

TSeg1= (Prop+Phase1)-1; minus 1 encoding
TSeg2= (Phase2)-1; minus 1 encoding

SJW= (4)-1; max allowed (and <= min Phase1/2)
SS= 0; 0/1 single/triple sampling

Baud= (SS<<23)+(TSeg2<<20)+(TSeg1<<16)+(SJW<<14)+(BPR<<0)

;------------------------------------------------------------------------
fn InitCAN

push{lr}; save regs
movsr0, pCAN2; enable peripheral clock
blPowerOn;
adrr0, canPins; Assign pins
blPinSetup;

ldrr3, =canBase; setup the CAN Controller
movsr0, 1; disable during setup
strr0, [r3, canMode];

ldrr0, =Baud; CAN bus timing details
strr0, [r3, canTiming];

movsr0, 0; clear errors/disable interrupts
strr0, [r3, canIntEnable];
strr0, [r3, canGStatus];
ldrr1, [r3, canIntStatus]; reset any interrupt flags
movsr1, (1<<3)+(1<<2)+(1<<1); abort tx, release rx, clr overrun
strr1, [r3, canCmd];

; set IRQ handler
; enable Rx Irq

movsr0, 0; enable controller
strr0, [r3, canMode];

ldrr3, =filtBase; bypass acceptance filter
movsr0, 3; and start accepting messages
strr0, [r3, filtCtrl];

ldrr0, =P112; bring CAN transciever
blPioSetDir; out of standby

pop{pc}; return

fe InitCAN

;------------------------------------------------------------------------
canPins:;Port    Pin      Count   Func  Flags
.word(0<<28)+(04<<20)+(2<<12)+(2<<8)+0x08; CAN
.word(1<<28)+(12<<20)+(1<<12)+(0<<8)+0x01, 0; GPIO

Cheers, Mike