Over the last couple of days I've been trying to use the BTUART on the
Ballon 3 without much success. All I want is to be able to listen to bytes
coming in on the BTRXD line. It appears that the PXA is actually holding
this line low[1].
After some musing between Wookey, Peter Clifton and myself we decided that
the appropriate GPIO Alternate Function Register were not being set
anywhere[2]. After figuring out how and where they should be set, Wookey
dutifully came up with a patch that adds:
pxa_gpio_mode(GPIO42_BTRXD_MD);
pxa_gpio_mode(GPIO43_BTTXD_MD);
pxa_gpio_mode(GPIO44_BTCTS_MD);
pxa_gpio_mode(GPIO45_BTRTS_MD);
to balloon_init() in linux/arch/arm/mach-pxa/balloon3.c. There is similar
code in lubbock.c and idp.c, although they put the above lines in their
foo_map_io() functions, which get called earlier. (I've also seen code that
assigns the GPIOs to the HWUART RXD and TXD lines, but this was on a PXA255
based board, and a 2.4 vintage kernel.)
Anyway - the patch does not appear to have achieved anything. The BTRXD line
is still being pulled down...
The kernel clearly thinks it has a BTUART. There is code in
linux/drivers/serial/pxa.c that declares it, and the FFUART, BTUART and
STUART are all listed during boot and all the /dev/ttyS* entries get
mknod'ed. The BTUART isn't listed in /proc/interrupts until you actually
try using it (cat /dev/ttyS1), and disappears again when you give up. The
number of interrupts received is always zero.
Electrically, it looks like the line goes straight from the PXA, through a
68R resistor, and on to the outside world. It doesn't look like it goes
anywhere near the FPGA or anything else that could affect it.
Any suggestions? I'm a bit stumped.
Paul.
[1] It's a bit fiddly trying to put a scope or meter on the line, and I can
really only measure anything after the BTRXD line has gone through a
68R resistor pack. With nothing else connected, the line appears to be
held
at 0V. If I connect something (the TX line of the device that I'm
trying
to listen to - which I can measure quite easily) then the line is
pulled
up, but only to about 2.5V or less.
A further puzzle is when the Balloon is first powered up, I can measure
3.3V on the line, but this drops to 2.5Vish after about 3 seconds. This
would suggest that it isn't an issue with any hardware, but is something
software related in the bootldr and/or kernel.
[2] It may actually be being set in bootldr. There is code in there that
does:
ldr r1, GAFR1L_Init_BALLOON3
str r1, [r0, #__OFFSET(GAFR1_L)]
where GAFR1L_Init_BALLOON3 is defined as:
GAFR1L_Init_BALLOON3: .long GAFR1L_InitValue
which in turn is computed in bootldr/asm-arm/arch-pxa/balloon3-init.h
which lists all the GPIO Alternate functions and default directions -
but it's hard to see what actually gets used and what doesn't with all
the #ifdef everywhere...
Paul Fidler
--
Cambridge University Engineering Department | Tel: +44 1223 332816
Trumpington Street, Cambridge, CB2 1PZ, UK | Fax: +44 1223 332662
(text/plain)