Hi All,
We have 3 boards in all 1)MCB2300 development board (LPC2378 based) 2)MCBSTM32C development board (STM32F107VCT06 based) 3)OEM Base Board QVGA v1.1 from Embedded Artists (LPC2478 based)
We have established communication between the first 2 ,however communication with the third board is failing.
We have ensured that the following things were taken care of : 1) Baud rates were the same 2) acceptance filter is in bypass mode 3) bus is free after a certain portion of time 4) interrupts are enabled 5) the format of sending and receiving the data is the same. 6) the registers have been checked from time to time.
The problems we are facing are 1) the routine for the reception in lpc2478 is never getting called when trying to detect a transmission from the other board.
The status of the GSR is initially 3C and then C. The Can_Handler provided in the demo code for the interrupts is never getting called.
The same routine when used for transmission within the same board between CAN1 and CAN2 controllers works perfectly well.
The errors being shown on the GSR vary from time to time ranging from 80005c-80007c.
2) the vice-versa also holds true . when the lpc2478 is transmitting the MCB2300 and MCBSTM32 are not able to recieve.
We are sure about the working of the routine in the other 2 boards as they can communicate with each other.
are we missing something. any help will be appreciated.
thank you.
A few things were brought to our notice while running the program in the debugger mode. When we were running the debugger , while receiving from another board, the few errors that we observed are : 1) bits: ID 21:28 stuff error 2) bit:error delimiter ,form error 3) The IRQ priority 1 turns into an FIQ 4) The control is never passed on to the correct address of the CAN_handler(interrupt routine).
We would again say that the same routine without any changes works perfectly well if we were to send a message from CAN1 to CAN2 on the same board and fails if another board is brought into picture.
Have you used a scope to check if the board seem to send using similar baudrate, so you don't have an error somewhere with your PCLK setting for the CAN device?
hi, i have indeed made sure that the baud rates are the same. It is strange that the same piece of code works well for a CAN controller placed on the same board but refuses to accept or transmit messages from the other board.
the keil uvision 4 debugger shows that there could possibly be a stuff error . If it is so how should we overcome the stuff error.
We feel that the transciever is only accepting a msg when it is transmitting simultaneously.Can this possibly be an obligation made by the CAN driver.
i have indeed made sure that the baud rates are the same.
To what level of precision? CAN has a significantly lower tolerance for baud rate differences than, say, RS232. A check with an oscilloscope may not be precise enough to make sure you're close enough.
It is strange that the same piece of code works well for a CAN controller placed on the same board but refuses to accept or transmit messages from the other board.
It's not actually all that strange for clock frequency differences to be bigger between different boards than between things running off the same clock, on the same board. ;-)
the keil uvision 4 debugger shows that there could possibly be a stuff error .
Bit stuffing errors are among the first symptoms of slight baud rate mismatches.
If it is so how should we overcome the stuff error.
By making sure your buad rates actually are the same.
Two issues here.
1) The oscilloscope don't verify the quality of the oscillators. It isn't exact enough. But it makes sure that the configuration bits are correct so there aren't an incorrect multiplier/divisor in PLL or somewhere else.
2) To verify the oscillator, it's hard to look at the CAN data. Much better to play with the timers. For example let a timer on one board generate pulses and have another board capture the pulses. Then you can measure differences in oscillator frequency of less than a part in a million without expensive hardware. You don't know which oscillator (or both) are off, but you at least know if they are reasonably similar.
3) The longer sequences (more bits) a hardware sends after it performed initial synchronization, the more important it is that the oscillators are close enough matched to not drift too much at last bits of burst.
And the fourth issue is that I can't count to three :D
View all questions in Keil forum