spidev config


8 posts
by devnull » Sat Sep 22, 2012 12:51 pm
I've been struggling all day to solve this, and have clicked probably the first 3 pages of links in google related but can't crack it.

I have another post on here regarding the Nokia Colour display and the speed problem, so I have now reverted to spidev to get better performance rather than bit bashing.

But I need to operate in 9 bit mode, and as soon as I change the SPI port to 9 bit using the bpw attribute and then send the writebytes() function, it crashes / hangs the entire system.

I am assuming that writebytes() is not limited to just 8 bit and that by setting the bpw (Bits Per Word) that the writebytes() is not limited to 8 bits.

Code: Select all
import spi
def main():
        x = spi.SPI(0,0)
        x.bpw = 9
        print x.bpw
        x.writebytes([0x1FF,0x100])


Would appreciate any help on this, as it has consumed pretty much all of Saturday and I have not solved it yet :-)

PeterC
> /dev/null 2>&1
Posts: 65
Joined: Sat Dec 24, 2011 7:46 am
by devnull » Sat Sep 22, 2012 1:45 pm
Could someone else run this code and see if you get the same system hang as I am getting ??

Thanks so much

PeterC
> /dev/null 2>&1
Posts: 65
Joined: Sat Dec 24, 2011 7:46 am
by devnull » Sun Sep 23, 2012 12:09 am
OK, seems like sending data with bit size other than 8 (the default) results in a kernel panic.

Here's the dump:
Code: Select all
[   92.076174] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[   92.183061] pgd = c0004000
[   92.224491] [00000000] *pgd=00000000
[   92.276552] Internal error: Oops: 17 [#1] PREEMPT

Entering kdb (current=0xcb836cc0, pid 5) Oops: (null)
due to oops @ 0xbf000368

Pid: 5, comm:          kworker/u:0
CPU: 0    Not tainted  (3.2.27+ #160)
PC is at bcm2708_work+0xd4/0x26c [spi_bcm2708]
LR is at process_one_work+0x134/0x38c
pc : [<bf000368>]    lr : [<c003dd84>]    psr: 60000013
sp : cb839f28  ip : c0530b54  fp : 00000000
r10: cba77724  r9 : ca72bf14  r8 : ca72bf34
r7 : 00000000  r6 : cb96cae0  r5 : cba776f8  r4 : ca72bef0
r3 : 00000003  r2 : 00000000  r1 : cba77708  r0 : cba77708
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 00c5387d  Table: 0bb70008  DAC: 00000017
[<c0013e1c>] (unwind_backtrace+0x0/0xf0) from [<c0377b28>] (kdb_dumpregs+0x28/0x50)
[<c0377b28>] (kdb_dumpregs+0x28/0x50) from [<c0071a04>] (kdb_main_loop+0x504/0x758)
[<c0071a04>] (kdb_main_loop+0x504/0x758) from [<c0073fd0>] (kdb_stub+0x13c/0x368)
[<c0073fd0>] (kdb_stub+0x13c/0x368) from [<c006afd4>] (kgdb_handle_exception+0x1fc/0x69c)
[<c006afd4>] (kgdb_handle_exception+0x1fc/0x69c) from [<c001359c>] (kgdb_notify+0x24/0x40)
[<c001359c>] (kgdb_notify+0x24/0x40) from [<c037e700>] (notifier_call_chain+0x44/0x84)
[<c037e700>] (notifier_call_chain+0x44/0x84) from [<c037e778>] (__atomic_notifier_call_chain+0x38/0x4c)
[<c037e778>] (__atomic_notifier_call_chain+0x38/0x4c) from [<c037e7a4>] (atomic_notifier_call_chain+0x18/0x20)
[<c037e7a4>] (atomic_notifier_call_chain+0x18/0x20) from [<c037e7e4>] (notify_die+0x38/0x44)
[<c037e7e4>] (notify_die+0x38/0x44) from [<c00114d8>] (die+0xb0/0x37c)
[<c00114d8>] (die+0xb0/0x37c) from [<c037744c>] (__do_kernel_fault.part.3+0x54/0x74)
[<c037744c>] (__do_kernel_fault.part.3+0x54/0x74) from [<c037e44c>] (do_page_fault+0x1a4/0x36c)
[<c037e44c>] (do_page_fault+0x1a4/0x36c) from [<c0008328>] (do_DataAbort+0x34/0x98)
[<c0008328>] (do_DataAbort+0x34/0x98) from [<c037cc98>] (__dabt_svc+0x38/0x60)
Exception stack(0xcb839ee0 to 0xcb839f28)
9ee0: cba77708 cba77708 00000000 00000003 ca72bef0 cba776f8 cb96cae0 00000000
9f00: ca72bf34 ca72bf14 cba77724 00000000 c0530b54 cb839f28 c003dd84 bf000368
9f20: 60000013 ffffffff
[<c037cc98>] (__dabt_svc+0x38/0x60) from [<bf000368>] (bcm2708_work+0xd4/0x26c [spi_bcm2708])
[<bf000368>] (bcm2708_work+0xd4/0x26c [spi_bcm2708]) from [<c003dd84>] (process_one_work+0x134/0x38c)
[<c003dd84>] (process_one_work+0x134/0x38c) from [<c003e7f8>] (worker_thread+0x1a0/0x354)
[<c003e7f8>] (worker_thread+0x1a0/0x354) from [<c0043190>] (kthread+0x84/0x8c)
[<c0043190>] (kthread+0x84/0x8c) from [<c000e930>] (kernel_thread_exit+0x0/0x8)
> /dev/null 2>&1
Posts: 65
Joined: Sat Dec 24, 2011 7:46 am
by c g » Sun Sep 23, 2012 11:16 am
According to the sources of the spi_bcm2708 module, 9 bits per word is not supported.
Posts: 7
Joined: Thu Sep 20, 2012 5:44 am
by devnull » Sun Sep 23, 2012 11:40 am
Hi;

Thanks, can you point me to where you found that info as ll I could find was for the BCM2835 which appears to support up to 32 bits ??

PeterC
> /dev/null 2>&1
Posts: 65
Joined: Sat Dec 24, 2011 7:46 am
by c g » Sun Sep 23, 2012 12:04 pm
BCM2708 is the family, BMC2835 is the specific implementation of the SoC that is used here.

Have a look into the sources of the kernel's SPI driver at https://github.com/raspberrypi/linux/bl ... 708.c#L238

I might be mistaken, but to me this looks like that you have to stick with bit-banging.
Posts: 7
Joined: Thu Sep 20, 2012 5:44 am
by devnull » Sun Sep 23, 2012 12:20 pm
Thanks very much, that's very helpful.

But I wonder if the developer has hard-coded the SPI to only run in 8 bit mode because of hardware limitation, or because that's what he felt most systems would use ?

How would I found out whether this is a limitation of the hardware itself, or whether it has been fixed to 8 bit by the developer, possibly during the initial design where it was set to the default for initial development / testing and never changed to allow the full scope of the chip ??

Thanks again.
> /dev/null 2>&1
Posts: 65
Joined: Sat Dec 24, 2011 7:46 am
by c g » Sun Sep 23, 2012 1:06 pm
The SPI controllers support bit lengths up to 32 bit ( http://www.raspberrypi.org/wp-content/u ... herals.pdf ).

I'd assume it's just a limitation of the driver, but you better ask Chris Boot ( http://www.bootc.net ), he's the developer.
Posts: 7
Joined: Thu Sep 20, 2012 5:44 am