Issues with Linux driver

[Wielomat]

To port an application to a newer embedded Linux system. I have to use your driver as I still need chardev.

During cross compilation I found out that I had to comment out CC=gcc in the make files of driver, lib and test as well as adding export CC=$(CROSS_COMPILE)gcc to the main Makefile. With this I was able to get everything compiled nut I'm not able to load the driver.

As we also emulate ISA communication with the external memory interface of the ARM controller we are using (AT91SAMA5D27-D1G) loading of the driver with following command

Code: Select all

insmod /lib/modules/4.14.73-linux4sam_6.0/misc/pcan.ko io=0x10000300 irq=5

fails with

Code: Select all

insmod: can't insert '/lib/modules/4.14.73-linux4sam_6.0/misc/pcan.ko': Numerical result out of range
Jan  1 00:04:37 pc104_wb12 user.err kernel: pcan: `0x10000300' invalid for parameter `io'

I already tried to use the SJA1000 driver from mainline kernel and I could load this one but I had to use parameter 'mem' instead of 'io' but the application has to use chardev and so I could not use the netdev driver.

Is there a way to modify yout kernel driver so it works as memory mapped device instead of strictly using ISA I/O?

[M.Maidhof]

Hi,

which CAN hardware from PEAK do you want to use on that system? Please post the IPEH-xxxxxx number.

regards

Michael

[Wielomat]

IPEH-002054

[S.Grosjean]

Hi,

About CC: as with any Makefile variable, you can override its default value with yours on the command line:

Code: Select all

$ make CC=blah-blah-gcc

should do the trick.

Next, AFAIU, you are now able to load the pcan driver *but* you can't use it with your PCAN-PC/104, right? I think the problem comes from the "io[]" array which is defined as an array of ushort values, while you want to define a 32-bit one. Can you please do the following changes:

In driver/src/pcan_fops.c, change:

Code: Select all

extern ushort io[8];
module_param_array(io, ushort, NULL, 0444);

into:

Code: Select all

extern ulong io[8];
module_param_array(io, ulong, NULL, 0444);

as well as, in driver/src/pcan_main.c, change:

Code: Select all

u16  io[8]    = {0, 0, 0, 0, 0, 0, 0, 0};

into:

Code: Select all

ulong  io[8]    = {0, 0, 0, 0, 0, 0, 0, 0};

Save then rebuild the driver.

Regards,

[Wielomat]

I know this is old but I still have some trouble with the driver.

Since last time I'm using v8.10.2 which fixed some of the issues I had (cross compile and larger range for isa addresses).
I still had to add a patch because I want to use the sja1000 as memory-mapped device but my controller does not have a native ISA controller, instead I use the external bus interface of the SAMA5D27-D1G and a PLD to generate the ISA timings. Because of that inb and outb do not work and I patched the driver to use the memory functions readb and writeb instead.

But now when I load the driver the probing stops after reading the status register because it reads 0x0c instead of 0x30 that the driver expects. If I understand the SJA1000 datashett correctly 0x30 means that it transmits and receives messages although nothing else is attached to CAN bus. 0x0c means that transmission is complete and buffer status is released.

Am I missing some bit swapping?
Patch file and log file attached

[S.Grosjean]

Hello,

I suspect problems with order processing times. By changing the read/write functions, you may have introduced problems in this area. For example, try to remove the comment in front of wmb(); (see line 1198 of driver/src/pcan_sja1000.c).

Regarding SR = 0x30:

see: https://www.nxp.com/docs/en/data-sheet/SJA1000.pdf page 30:

"If both bits are set the controller is waiting to become idle again."

Do not confuse them with RBS and TBS bits!

Regards,

[Wielomat]

I found the problem for that issue. I misconfiguered the external bus interface to use 16-Bit wide accesses, now with8-bit wide accesses I can load the kernel module and get a character device for CAN.

But I ran into another issue.To reproduce this I did the following:
- load the kernel module
- start receivetest
- send a CAN message from another PC

As soon as the CAN message arrives at the SJA1000 it activates its interrupt line and the embedded linux runs into a kernel panic.

The attached file contains the previouse changes to request_mem_region instead of request_region as our controller does set IO size to 0 as well was some additional debuf prints when accessing the SJA1000. And as I have a GPIO pin as interrupt I switched the irq kernel parameter to be an gpio number as this was easier than to find out the corresponding irq number.
The other file is the log of the console of the embedded linux.

in those logs 73 is the gpio number of pin PC9 of the SAMA5D27 which translates to irq number 112 as I know now.

[S.Grosjean]

Hi,

ioremap() and "iounmap()' might nor be atomic functions. You can't use them like this. You should instead do only once "ioremap()" (in pcan_isa_init() for example) and only once "iounmap()" (in pcan_isa_cleanup() for example).
Save the resulting iomen pointer into struct pcandev, then, only change inb() (resp. outb()) by readb() (resp. writeb()) in pcan_isa_readreg() (resp. pcan_isa_writereg()).

Regards,

[Wielomat]

OK, meanwhile I can send and receive messages but ran into other problems that seems driver related.

If I run "pcanfdtst tx <path/to/dev>" it starts sendingrandom messages as expected but at some some the messages are no longer sent over the CAN bus and the transmit buffer fills up to its maximum value. Closing and restarting the program works again for a while.
What could be the cause that the messages are no longer read from tx_fifo?

In our program we use CanOpen as our CAN stack and sometimes the received messages have different lengths. In PCAN Explorer I see this if a message with a known CAN-ID is received but the data are only shown as hexadecimal values instead of decoded values.
I'm using a PCAN-USB dongle and PCAN Explorer to examine the messages on the CAN bus.

[M.Heidemann]

Hello,

Please try to be forum-specific with your questions,
as PCAN-Explorer related questions do not belong here.

Please check if checking "Valid for all data lengths" in the symbol properties solves your issue:

ValidForAllDataLengths.PNG (11.19 KiB) Viewed 8107 times

Best Regards

Marvin