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
hi,
we are delving deeper into the baud rate issue. we initially were just making sure that the hex values put in the BTR register are the same and the BRB ,SJW,TSEG1 and TSEG2 are all the same. Is that insufficient for the setting of baud rate?
You only talk about configuration values used in the CAN controller. You don't tell us anything about the board having the crystal frequency you actually think it has. And the PLL being correctly configured. And the peripherial clock divisor register being correctly configured. If the CAN block gets an incorrect clock frequency supplied, then your calculated values for the CAN controller will still result in the wrong baudrate.
hi all, we have solved the problem partially. It was in fact a baud rate issue. the baud rates when matched , the "Embedded artist OEM "board is able to receive and transmit easily.
Although the 2 functions are not able to work simultaneously. Could there be any possible reason for that?
also we notice that when the controller GSR reaches an idle status , it is never able to wake up even if the board on the other side is transmitting. Does this imply an issue with the interrupts?
A single CAN controller can't send and receive at the same time - except that it can normally be configured to accept its own transmissions.
If fed data to transmit, it can interleave transmission and reception, based on the priorities of the received frames in relation to the priorities of the outgoing frames.
A processor with two CAN interfaces should be able to operate the two interfaces completely separated. So having different baudrates and having zero timing interaction between them except for the interaction when the interrupt handler consumes clock cycles and delaying the execution of interrupts for the other interface.
By the way - what was wrong with the baudrate?
the issue with the baud rate was that even though theoretically the baud rates of the 2 controllers was the same, the oscilloscopes showed a difference of more than 50kHz. We looked at the intervals between the stuff bits and adjusted the baud rate accordingly.
Now the problem we are facing is that there is data overrun after transmitting and receiving a few values also the bus status becomes off i.e. the tx error reaches its limits. Bits from 8-15 are reserved in the GSR , however these bits get written on during transmission.
Could this also be a timing issue ?
If we assume 1Mbit/s is used, and you have an error of 50kHz, that is 5% off.
No processor crystal has such errors - so how come you got so huge baudrate errors? If we assume 100ppm max error, and the two board have max error in different direction, then you should not be able to measure more than 0.02% frequency error. And getting two boards that are 100ppm off in different directions is very unlucky.
Is the processor incorrectly configured to use an RC oscillator? Even laser-trimmed RC oscillators are way better than this. Or have you made a serious mistake somewhere in configuring the PLL?