Am Mi, 19.02.2014, 23:05 schrieb Wayne Ross: > On Wednesday, February 19, 2014 3:16 AM Wolfgang Grandegger wrote: > > > > Am Di, 18.02.2014, 23:00 schrieb Wayne Ross: > >>> On Monday, February 17, 2014 3:21 PM, Wolfgang Grandegger >>> <[email protected]> wrote: ... >>> dmesg shows new activity: rtcan0: real bitrate 250000, sampling point >>> 87.5% >>> rtcan_sja_set_bit_time: btr0=0x1 btr1=0x1c >>> rtcan1: real bitrate 250000, sampling point 87.5% >>> rtcan_sja_set_bit_time: btr0=0x1 btr1=0x9c >>> >> >> That's strange. "btr1" should here be "0x1c" as well. >> >> > *Most* times I start after boot, BOTH report btr1=0x9c... > One boot I saw the values swapped.
That's wired == not OK! btr1 should always be "0x1c". > I have tried transmits with either register value, same results, only ever > 1 message, no errors seen at CANalyzer. The BTR might be used for > receiving data, not transmitting though. Looking at the > rtcan_calc_bit_time() routine in rtcan_raw_dev.c, it appears the same > answer should always be provided. One CAN message does show up on the bus! Then ... > >>> >>> cat /proc/rtcan/devices shows: Name___________ _Baudrate State___ >>> TX_Counter RX_Counter ____Errors >>> rtcan0 250000 active 0 0 0 >>> rtcan1 250000 active 1 0 0 >> >> A few questions: >> >> >> - What does "/proc/xenomai/irq" list after you have sent a message? >> > # cat /proc/xenomai/irq > IRQ CPU0 CPU1 CPU2 CPU3 > 12: 0 0 0 0 SJA1000 > 15: 0 0 0 0 SJA1000 ... the problem is here. No interrupts are triggered. Are your sure that the IRQ numbers are correct (check jumpers on the card/board)? >> - Is your CAN cable connected and terminated properly? >> > Yes. This is first time for linux CAN, but I have been using CAN for 13 > years. 120 Ohm resister on each end of bus when connecting rtcan0 to > rtcan1. CANAlyzer shows 1 "clean" message seen with either 1 or 2 > resisters present. This same configuration will run with Advantech's > provided linux driver at about 10ms intervals for transmits, and is OK. > This is same as my old hardware -- very forgiving if 1 resister is > missing at this slow of baud rate and short of a bus. I am trying to use > xeno_can_mem to reduce muliple milli-second transmit jitter seen using > that other driver. OK. >> - Could you connect an external CAN node/analyser to test message >> transmission from and to rtcan0? >> > > Again, I get a single message seen with rtcansend. > Does not matter if rtcan1 is connected only to CANalyzer or both CANalyzer > and rtcan0. If I ask for rtcansend --loop=10, only 1 message followed by > task "hang". And /proc/xenomai/irq shows no interrupts processed. > I'd guess that means the software isn't being told "transmit buffer > empty". > > Testing rtcanrecv: no data ever shows as arrived. > BUT, I can see the physical RX LED on the circuit board blink that a > change in state was seen on the bus. No IRQ counts in > /proc/xenomai/irq. This is the same if I use either rtcan0 or rtcan1 > alone with CANalyzer. > > If no driver has initialized the CAN card, the RX LED will stay lit, and > the CANalyzer transmitting the message will show "ErrorFrame". If I then > initialize the port with Advantech driver, the LED stays lit. It is not > until I have a test program open that port and execute a IOCTL that > requests a read of that port that the light is removed. In the case of > Xenomai, the two steps of "modprobe xeno_can_mem" followed by > "rtcanconfig" is enough to extinquish the LED. So it appears some > handshake takes place enough to clear the hardware. And /proc/xenomai/irq > still shows no IRQ activity. The TX and RX behaviour you described above is due to no IRQs arriving. That's the main problem. > > Fresh reboots between all trials, in case anything is "hanging around". > > > Just in case, I also include "cat /proc/interrupts": > CPU0 CPU1 CPU2 CPU3 > 0: 41 0 0 0 IO-APIC-edge timer > 8: 0 1 0 0 IO-APIC-edge > rtc0 9: 0 0 0 0 IO-APIC-fasteoi > acpi 14: 388 412 422 396 IO-APIC-edge > ata_piix 15: 0 0 0 0 IRQ 15 is already in use by Linux. You should avoid sharing interrupts with Linux used by Linux. Anyway, that's not the case for IRQ 12. Wolfgang. _______________________________________________ Xenomai mailing list [email protected] http://www.xenomai.org/mailman/listinfo/xenomai
