Re: [Xenomai] CAN ISA support

Re: [Xenomai] CAN ISA support

[Wayne Ross]

On Thursday, February 20, 2014 3:19 AM Gilles Chanteperdrix wrote:

> On 02/20/2014 08:47 AM, Wolfgang Grandegger wrote:
>> Am Mi, 19.02.2014, 23:05 schrieb Wayne Ross:
>>> On Wednesday, February 19, 2014 3:16 AM Wolfgang Grandegger wrote:
>>>> - 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)?>
>You can also check cat /proc/interrupts when using the Linux driver.
>
>-- 
>                                                                Gilles.


Thanks for all the in-sight.  Tracing down this lack of interrupts led me to the following solution:
- the Advantech driver *transmits* without the aid of IRQs, so I "thought" it was working, when indeed no IRQs were seen.
- I had never tried to receive CAN with the Advantech driver: when I did so, it would not (no IRQs)
- I found the setting in my v2.61 American Megatrends BIOS that allows "Legacy IRQs" to be "Reserved" (not allowed to be used by PCIPnP).
- I also had to select different IRQs that all components (BIOS, CAN card, 4 16550A UARTs & some ata/acpi Linux drivers) agree were unused and I could tag as "Reserved"
- In hindsight, all of this should have been done first, but such is the lesson learned when venturing down a new road.  I'm not used to dealing with a BIOS that gets between the chips on my board and the software I write.

I intend to look more at the btr1 register "issue".  As Wolfgang mentions, it *should* be 0x1c, so only sometimes do I get the correct value.  I think the 0x9c means "3 samples" (instead of 1) -- at least when I put these register settings into my Windows driver, that is how that software decodes the meaning.  But it does indeed transmit and receive thousands of messages without a problem.

Thanks again
          Wayne

Re: [Xenomai] CAN ISA support

[Wolfgang Grandegger]

On 02/25/2014 05:23 PM, Wayne Ross wrote:
> On Thursday, February 20, 2014 3:19 AM Gilles Chanteperdrix wrote:
> 
>> On 02/20/2014 08:47 AM, Wolfgang Grandegger wrote:
>>> Am Mi, 19.02.2014, 23:05 schrieb Wayne Ross:
>>>> On Wednesday, February 19, 2014 3:16 AM Wolfgang Grandegger wrote:
>>>>> - 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)?>
>> You can also check cat /proc/interrupts when using the Linux driver.
>>
>> -- 
>>                                                                 Gilles.
> 
> 
> Thanks for all the in-sight.  Tracing down this lack of interrupts led me to the following solution:
> - the Advantech driver *transmits* without the aid of IRQs, so I "thought" it was working, when indeed no IRQs were seen.

It works for just one message.

> - I had never tried to receive CAN with the Advantech driver: when I did so, it would not (no IRQs)

You mean you only sent messages with the Advantech driver?

> - I found the setting in my v2.61 American Megatrends BIOS that allows "Legacy IRQs" to be "Reserved" (not allowed to be used by PCIPnP).

BIOS settings may need the be adjusted but I understood that the device
was already working with another driver.

> - I also had to select different IRQs that all components (BIOS, CAN card, 4 16550A UARTs & some ata/acpi Linux drivers) agree were unused and I could tag as "Reserved"

> - In hindsight, all of this should have been done first, but such is the lesson learned when venturing down a new road.  I'm not used to dealing with a BIOS that gets between the chips on my board and the software I write.

Does it now work (with IRQs)?

> I intend to look more at the btr1 register "issue".  As Wolfgang mentions, it *should* be 0x1c, so only sometimes do I get the correct value.  I think the 0x9c means "3 samples" (instead of 1) -- at least when I put these register settings into my Windows driver, that is how that software decodes the meaning.  But it does indeed transmit and receive thousands of messages without a problem.

Yes, that's weird.  Maybe there are register access problems.

Wolfgang.

Re: [Xenomai] CAN ISA support

[Wayne Ross]

On Thursday, February 20, 2014 2:47 AM Wolfgang Grandegger wrote:
> 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
>>>> <wg@grandegger.com> 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".
>
> Wolfgang.
 
Researching
this some more, I *think* I have tracked down this behavior to an
uninitialized variable in the file ksrc/drivers/can/rtcan_raw_dev.c, routine
rtcan_cal_bit_time(): this function is called by rtcan_ioctl_dev_set(),
passing a can_bittime pointer.  At the end of rtcan_calc_bit_time, 5
members of that structure (bt) are filled out, not touching 1 value (sam, a single bit) leaving it uninitialized.  I don't see any
initialization of that structure in the calling routine either. 


I
see the alternate Kernel configuration of
CONFIG_XENO_DRIVERS_CAN_CALC_BITTIME_OLD earlier in the file always sets this
value to 0.

 I
cannot see any reason to have this value unset for the STD
calculation. 

include/rtdm/rtcan.h describes this bit as "enable triple sampling", which is probably available
for a custom timing. 

So, I
propose the following change:
diff --git a/ksrc/drivers/can/rtcan_raw_dev.c b/ksrc/drivers/can/rtcan_raw_dev.c
index c5fd1b6..d305bab 100644
--- a/ksrc/drivers/can/rtcan_raw_dev.c
+++ b/ksrc/drivers/can/rtcan_raw_dev.c
@@ -219,6 +219,7 @@ static int rtcan_calc_bit_time(struct rtcan_device *dev,
     bt->phase_seg1 = tseg1 - bt->prop_seg;
     bt->phase_seg2 = tseg2;
     bt->sjw = 1;
+    bt->sam = 0;
     bt->brp = best_brp;
 
     /* real bit-rate */


With this change I have confirmed rtcanconfig *always* yields the *same* result for btr1 (0x1c):
rtcan0: real bitrate 250000, sampling point 87.5%
rtcan_sja_set_bit_time: btr0=0x1 btr1=0x1c


Wayne

Re: [Xenomai] CAN ISA support

[Wolfgang Grandegger]

On Thu, 20 Mar 2014 06:31:45 -0700 (PDT), Wayne Ross
<mr_trekkie@yahoo.com> wrote:
> On Thursday, February 20, 2014 2:47 AM Wolfgang Grandegger wrote:
>> 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
>>>>> <wg@grandegger.com> 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".
>>
>> Wolfgang.
>  
> Researching
> this some more, I *think* I have tracked down this behavior to an
> uninitialized variable in the file ksrc/drivers/can/rtcan_raw_dev.c,
> routine
> rtcan_cal_bit_time(): this function is called by rtcan_ioctl_dev_set(),
> passing a can_bittime pointer.  At the end of rtcan_calc_bit_time, 5
> members of that structure (bt) are filled out, not touching 1 value
(sam,
> a single bit) leaving it uninitialized.  I don't see any
> initialization of that structure in the calling routine either. 
> 
> 
> I
> see the alternate Kernel configuration of
> CONFIG_XENO_DRIVERS_CAN_CALC_BITTIME_OLD earlier in the file always sets
> this
> value to 0.
> 
>  I
> cannot see any reason to have this value unset for the STD
> calculation. 
> 
> include/rtdm/rtcan.h describes this bit as "enable triple sampling",
which
> is probably available
> for a custom timing. 
> 
> So, I
> propose the following change:
> diff --git a/ksrc/drivers/can/rtcan_raw_dev.c
> b/ksrc/drivers/can/rtcan_raw_dev.c
> index c5fd1b6..d305bab 100644
> --- a/ksrc/drivers/can/rtcan_raw_dev.c
> +++ b/ksrc/drivers/can/rtcan_raw_dev.c
> @@ -219,6 +219,7 @@ static int rtcan_calc_bit_time(struct rtcan_device
> *dev,
>      bt->phase_seg1 = tseg1 - bt->prop_seg;
>      bt->phase_seg2 = tseg2;
>      bt->sjw = 1;
> +    bt->sam = 0;
>      bt->brp = best_brp;
>  
>      /* real bit-rate */
> 
>

Acked-by: Wolfgang Grandegger <wg@grandegger.com>
 
> With this change I have confirmed rtcanconfig *always* yields the *same*
> result for btr1 (0x1c):
> rtcan0: real bitrate 250000, sampling point 87.5%
> rtcan_sja_set_bit_time: btr0=0x1 btr1=0x1c

Good catch!

Thanks,

Wolfgang.