Hi all,
I am trying to get a Beagleboard rev. B7 to talk to the atmega on the
Trainer expansion board - so far with no success. Flashed the Arduino
bootloader to the atmega with an external programmer in advance. The
Trainer's LED2 is constantly on while LED1 is blinking. Then tried to
upload a sketch from the beagleboard with avrdude, but the response
always remains the same:
root@beagleboard:~# avrdude -V -F -c stk500v1 -p m328p -P /dev/ttyS1 -
b 57600 -U
flash:w:mysketch.hex -vvvv
Using Port : /dev/ttyS1
Using Programmer : stk500v1
Overriding Baud Rate : 57600
avrdude: Send: 0 [30] [20]
avrdude: Send: 0 [30] [20]
avrdude: Send: 0 [30] [20]
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
Tried with the following beagleboard images (always in combination
with the corresponding U-Boot):
- Test image (as suggested on the Trainer Wikipage)
- Beagleboard demo from http://angstrom-distribution.org/demo/beagleboard/
- generated unstable image from http://www.angstrom-distribution.org/narcissus/
- built from openembedded source
The Trainer always gets recognized from u-boot:
Recognized Tincantools Trainer expansion board (rev 0 0)
Beagle Rev Ax/Bx
Die ID #314600030000000004013f7806008012
... output from dmesg:
[ 0.000000] Beagle expansionboard: trainer
[ 0.000000] Beagle expansionboard: exporting GPIOs 130-141,162 to
userspace
.. but i am not able to connect to the atmega through /dev/tty/S1.
Are there known issues with the Trainerboard and Beagleboard rev. B7?
Are there differences in the pin-muxing between current and older
revisions?
Has anybody already had any experience with rev. B7 and the Trainer
board?
Thanks in advance for any help or suggestions!
best,
silvanji
I suspect a revB will need a different mux for the serialport. I can look into it after the weekend if noone beats me to it. I suspect the same is true for the zippy and zippy2 boards.
regards,
Koen
The expansion pins are definitley different on Rev B7. This is desribed in the System Manual for the Rev C. Three pins did move, but I don’t know how the Zippy board uses them. I would ping TinCan Tools and see if they it on a Rev B7 or not and how these pins are used.
Gerald
Thanks for the replies!
RevB7 SRM, Expansion connector signals table (p. 83) specifies the
MCBSP3
signals as relevant for UART2. And from the pin mux wikipage i could
find
out that exactly these signals (except MCBSP3_FSX) are different
between
RevB and RevC:
BB J3|BB Desc. |RevB GPIO|RevC GPIO|OMAP Pin RevB|OMAP Pin RevC|U-
Boot
4 |MCBSP3_DX |140 |144 |AF6 |AB26 |
MCBSP3_DX
6 |MCBSP3_CLKX |142 |146 |AF5 |AA25 |
MCBSP3_CLKX
10 |MCBSP3_DR |141 |145 |AE6 |AB25 |
MCBSP3_DR
The MUX_* functions in beagle.h set gpio 144-147 for the UART2_*
registers in
MUX_BEAGLE() and gpio 140-142 for the MCBSP3_* registers ...
I'm currently a little confused about where to intervene - the mapping
of
the names to the actual registers are probably not in the u-boot
configuration.
best regards,
silvanji
Hi Silvanji
RevB and RevC:
BB J3|BB Desc. |RevB GPIO|RevC GPIO|RevB |RevC |U-Boot
4 |MCBSP3_DX |140 |144 |AF6 |AB26 | MCBSP3_DX
6 |MCBSP3_CLKX |142 |146 |AF5 |AA25 | MCBSP3_CLKX
10 |MCBSP3_DR |141 |145 |AE6 |AB25 | MCBSP3_DR
The MUX_* functions in beagle.h set gpio 144-147 for the UART2_*
registers in MUX_BEAGLE() and gpio 140-142 for the MCBSP3_* registers ...
I'm currently a little confused about where to intervene - the mapping
of the names to the actual registers are probably not in the u-boot
configuration.
This is indeed one of the confusing thing about OMAP pinmuxing. You need to
look at both the Data Manual [1] and the TRM [2] at the same time to figure
out. In the TRM you need to check chapter 7 (System Control Module) and in
the DM you need to find the name of a given ball from its location on the
ballout...
[1] http://focus.ti.com/lit/ds/symlink/omap3530.pdf
[2] http://focus.ti.com/lit/ug/spruf98g/spruf98g.pdf
Since you have the GPIO number (from the table above) you can do a shortcut
an just search for this on in the TRM (i.e. GPIO_140), which will show you
the name of the register to modify in U-boot in order to change the muxing
for this particular ball...
Hope this helps you forward - Good luck
Søren
Good news, got it working!
The various MUX_* functions in
{$U-BOOT-SRC}git/board/ti/beagle/beagle.h seem to do the
mux magic. MUX_BEAGLE() get's called in any case
via set_mugsconf_regs() in beagle.c, then misc_init_r() takes
care of revision-, and expansionboard specific settings by calling
the appropriate MUX_* functions. In case a trainer could be detected,
MUX_TINCANTOOLS_ZIPPY() and MUX_TINCANTOOLS_TRAINER()
are called. A separate MUX_BEAGLE_C() function seems to take
care of the different assignments between RevB and RevC boards.
MUX_BEAGLE() initializes the MCBSP3_* pins in gpio mode (M1)
which corresponds with the assignments in RevB boards. The _ZiPPY(),
_TRAINER() and _C() mux methods assign gpio mode as well but
as mode 4 (M4) - which is correct for RevC boards. All i had to do
is to comment out the MUX_VAL() calls for the MCBSP3_ pins in the
_ZIPP() and _TRAINER() mux methods to get it working.
This brings up some more question:
- Is the reasoning above basically correct?
- I would like to create a propper patch; Would it be ok to query the
beagle revision in the _ZIPPY() and _TRAINER() methods before
muxing the MCBSP3* pins?
Another general question:
- What about the UART2* pins; The beagle PinMux wikipage states
that the register names are deducted from mode0 of the respective
pin, but i don't see any pins with UART2* functionality in SRM of
RevB,
and the latest SRM has UART2 modes on mode0 but no MCBSP3
anymore ... What's the interrelation between MCBSP3* in gpio mode
the UART2* pins in mode4 (which seems not available according to the
RevB SRM and is specified as gpio in the latest SRM).
Anyways, for today i'm happy to be able to play with BB and the
atmega 
Best regards,
silvanji
Hi Silvanji,
Good news, got it working!
Great 
This brings up some more question:
- Is the reasoning above basically correct?
You reasoning is/was correct as much as I can follow
- I would like to create a propper patch; Would it be ok to query the
beagle revision in the _ZIPPY() and _TRAINER() methods before
muxing the MCBSP3* pins?
I think it would be OK, although others might have other opinions. In your
case I would go ahead and do what you find a proper patch and then send it
to the list. Then I'm sure that someone will pick it up, comment and even
add it to the main OE tree in order to push it upstream if the find it OK...
Another general question:
What about the UART2* pins; The beagle PinMux wikipage states
that the register names are deducted from mode0 of the respective
pin, but i don't see any pins with UART2* functionality in SRM of RevB,
and the latest SRM has UART2 modes on mode0 but no MCBSP3
anymore ... What's the interrelation between MCBSP3* in gpio mode
the UART2* pins in mode4 (which seems not available according to the
RevB SRM and is specified as gpio in the latest SRM).
For this please have a look at the OMAP3 TRM
(http://focus.ti.com/lit/ug/spruf98g/spruf98g.pdf) chapter 7.4.4.3. This one
gives the full explanation of the balls compared to all possible muxing
possibilities. Secondly the DM
(http://focus.ti.com/lit/ug/spruf98g/spruf98g.pdf) is needed in order to
relate the above table (from the TRM) to the actual physical balls on the
OMAP. See chapters 2.3 and 2.4 - Beagle is using the CBB variant of the
chip...
Best regards
Søren