We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
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.
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?
hi,
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?