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: >> >> Secondary problem: only 1 message can be sent with rtcansend. >> >> Details: >> Looking at the RT-Socket-CAN Utilities: >> Run: ./rtcanconfig rtcan0 --baudrate=250000 start >> and: ./rtcanconfig rtcan1 --baudrate=250000 start > > The above two commands are mandatory before you can send/recv messages. > >> 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. 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. >> >> 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 2304: 1 0 2 2 [reschedule] 2305: 12354 7182 4331 4320 [timer] 2306: 1 0 1 1 [timer-ipi] 2307: 0 0 0 0 [sync] 2339: 6 1 0 0 [virtual] > - 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. > - 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. 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 IO-APIC-edge ata_piix 16: 0 4 874 5 IO-APIC-fasteoi uhci_hcd:usb5, i915, p36p1 18: 0 0 0 0 IO-APIC-fasteoi ata_piix, uhci_hcd:usb4 19: 0 0 0 0 IO-APIC-fasteoi uhci_hcd:usb3 21: 103 102 104 103 IO-APIC-fasteoi snd_hda_intel 23: 9827 33 30 31 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb2, eth0 NMI: 0 0 0 0 Non-maskable interrupts LOC: 118132 8137 3104 2911 Local timer interrupts SPU: 0 0 0 0 Spurious interrupts PMI: 0 0 0 0 Performance monitoring interrupts IWI: 36 548 69 78 IRQ work interrupts RTR: 0 0 0 0 APIC ICR read retries RES: 2434 2774 2591 3605 Rescheduling interrupts CAL: 155 127 362 212 Function call interrupts TLB: 132 148 220 160 TLB shootdowns TRM: 0 0 0 0 Thermal event interrupts THR: 0 0 0 0 Threshold APIC interrupts MCE: 0 0 0 0 Machine check exceptions MCP: 6 6 6 6 Machine check polls ERR: 0 MIS: 0 Wayne _______________________________________________ Xenomai mailing list [email protected] http://www.xenomai.org/mailman/listinfo/xenomai
