Mity CPU Platforms » MityDSP-L138 (ARM9 Based Platforms)

I have attached the files defining the class and showing how I open the serial port. Then I just use standard write calls using termHandle.

Hello,

Is is possible your kernel may not be setting up the ARM pin multiplexing for UART2? In your baseboard file [arch/arm/mach-davinci/baseboard-industrialio.c if your using the industrial IO build], you probably need something like:

/**
 * UART2 Pins.
 */
static short baseboard_uart2_pins[] __initdata = {
        DA850_UART2_RXD,
        DA850_UART2_TXD,
        -1,
};

davinci_cfg_reg_list(baseboard_uart2_pins);

Then rebuild the kernel.

- Dominic

How would anyone know this? I have looked at the config of the kernel I am using and you are correct, these pins are not mentioned in the .config file. I built the kernel based on the instructions in the wike, and there is nowhere the I could find in menuconfig that you can configure UART2. But shouldn't I see the GPIO toggle for TX_ENB? (unless the value I use for the GPIO pin is incorrect) - bank 0 pin 9 should be 9, correct?

Hi Steven,

Sorry for the confusion. It's not a menuconfig item. There is a patch needed to enable the UART2 pin pinmuxes (it didn't appear to get ported to the 3.2 kernel).

I will post the patch (push it to the git mitydsp-linux-v3.2 branch) update this thread to let you know it is there (hopefully in a few minutes). Then you need to do a pull and rebuild.

For the TX_ENB, you should see the GPIO pin toggle with what you have even of the UART TX/RX pins aren't pinmuxed correctly. Bank 0 pin 9 is correct, so I am not entirely sure what the issue is.

Can you please confirm you are using the mitydsp-linux-v3.2 branch and run a "uname -a" for me so that I know we are referring to the same kernel codebase?

-Mike

OK. I have added the patch to the mitydsp-linux-v3.2 branch. You should be able to at least see the Tx line toggle with your code.

If you can confirm you are getting normal output on the Tx lines, then we can tackle the TXE issue. We've tested the TXE logic a couple of times on different baseboards, so there must be something minor for the IOCTL setup.

I am sorry for the inconvenience.

-Mike

Thanks for your response. Here is what I get from uname:
Linux mityomapl138 3.2.0 #1 PREEMPT Wed May 15 09:16:03 EDT 2013 armv5tejl GNU/Linux

A newbie question - How do I build this particular branch of the kernel?

If you have our repository cloned already....

git checkout -b mitydsp-linux-v3.2 origin/mitydsp-linux-v3.2
make ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- industrialio_defconfig
make ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- uImage

-Mike

I'm getting errors when I try to build the kernel:

mitydsp@mitydsp-VirtualBox:~/linux-davinci$ make ARCH=arm CROSS-COMPILE=arm-angstrom-linux-gnueabi- uImage
scripts/kconfig/conf --silentoldconfig Kconfig
WRAP arch/arm/include/generated/asm/auxvec.h
WRAP arch/arm/include/generated/asm/bitsperlong.h
WRAP arch/arm/include/generated/asm/cputime.h
WRAP arch/arm/include/generated/asm/emergency-restart.h
WRAP arch/arm/include/generated/asm/errno.h
WRAP arch/arm/include/generated/asm/ioctl.h
WRAP arch/arm/include/generated/asm/irq_regs.h
WRAP arch/arm/include/generated/asm/kdebug.h
WRAP arch/arm/include/generated/asm/local.h
WRAP arch/arm/include/generated/asm/local64.h
WRAP arch/arm/include/generated/asm/percpu.h
WRAP arch/arm/include/generated/asm/poll.h
WRAP arch/arm/include/generated/asm/resource.h
WRAP arch/arm/include/generated/asm/sections.h
WRAP arch/arm/include/generated/asm/siginfo.h
WRAP arch/arm/include/generated/asm/sizes.h
CHK include/linux/version.h
UPD include/linux/version.h
CHK include/generated/utsrelease.h
UPD include/generated/utsrelease.h
Generating include/generated/mach-types.h
CC kernel/bounds.s
cc1: error: unrecognized command line option ‘-mlittle-endian’
cc1: error: unrecognized command line option ‘-mno-thumb-interwork’
kernel/bounds.c:1:0: error: unknown ABI (aapcs-linux) for -mabi= switch
kernel/bounds.c:1:0: error: bad value (armv4t) for -march= switch
kernel/bounds.c:1:0: error: bad value (arm9tdmi) for -mtune= switch
make¹: * [kernel/bounds.s] Error 1
make: * [prepare0] Error 2

I ran the environment setup script before doing this - creating the config file seemed to work fine.

You only use the HOST native CC, not the cross tools, to build the config file. It seems like you have a CC environment variable set and it's pointing to a native (x86) gcc.

Can you please launch a new shell and run the setup script? The errors you are reporting typically mean the cross tool path isn't setup properly.

-Mike

I seem to have the same problems - here is the output from a new shell:

mitydsp@mitydsp-VirtualBox:~$ . /usr/local/oecore-i686/environment-setup-armv5te-angstrom-linux-gnueabi
mitydsp@mitydsp-VirtualBox:~$ cd linux-davinci
mitydsp@mitydsp-VirtualBox:~/linux-davinci$ git checkout -b mitydsp-linux-v3.2 origin/mitydsp-linux-v3.2
fatal: A branch named 'mitydsp-linux-v3.2' already exists.
mitydsp@mitydsp-VirtualBox:~/linux-davinci$ make ARCH=arm CROSS-COMPILE=arm-angstrom-linux-gnueabi- industrialio_defconfig
#
# configuration written to .config
#
mitydsp@mitydsp-VirtualBox:~/linux-davinci$ make ARCH=arm CROSS-COMPILE=arm-angstrom-linux-gnueabi- uImage
scripts/kconfig/conf --silentoldconfig Kconfig
  CHK     include/linux/version.h
  CHK     include/generated/utsrelease.h
make[1]: `include/generated/mach-types.h' is up to date.
  CC      kernel/bounds.s
cc1: error: unrecognized command line option ‘-mlittle-endian’
cc1: error: unrecognized command line option ‘-mno-thumb-interwork’
kernel/bounds.c:1:0: error: unknown ABI (aapcs-linux) for -mabi= switch
kernel/bounds.c:1:0: error: bad value (armv4t) for -march= switch
kernel/bounds.c:1:0: error: bad value (arm9tdmi) for -mtune= switch
make[1]: *** [kernel/bounds.s] Error 1
make: *** [prepare0] Error 2
mitydsp@mitydsp-VirtualBox:~/linux-davinci$ 

Sorry - my mistake. I re-installed the toolchain and then realized that I had typed "CROSS-COMPILE" instead of "CROSS_COMPILE". Kernel generation seems to be working now.

It is necessary to have the incantations exactly correct!

OK, I built the new kernel and flashed it to the MityDSP - now uname gives:

Linux mityomapl138 3.2.0+ #1 PREEMPT Thu Jul 18 11:44:18 PDT 2013 armv5tejl GNU/Linux

But, I am still not seeing any toggling of Tx lines or the TX_ENB lines, using the code I sent earlier.

Have I compiled the kernel correctly? Do I have to do the git checkout immediately before building the kernel?

Steven,

Run the command git branch to see which branch is selected. It should say mitydsp-linux-v3.2. When you run git log you should see the UART2 change at the top.

-Jonathan

Btw press q to escape git log.

I am assuming it compiled OK.

Are you sure that the write() call is returning successfully? Can you send the full example, or modify the stand alone examples (in c) and try them?

Also, you should be able to just

echo "hello" > /dev/ttyS2

and monitor the Tx line to see some activity. That would remove all the code and make sure the board and your instrumentation is OK.

-Mike

OK, here is what I see:

• mitydsp-linux-v3.2
  mitydsp@mitydsp-VirtualBox:~/linux-davinci$ git log
  commit f13cb8373517840670b06fafc1b381e934c5ac37
  Author: Michael Williamson <michael.williamson@criticallink.com>
  Date: Wed Jul 17 21:04:28 2013 -0400

ARM: DAVINCI: IndustrialIO Baseboard: Enable UART2 Tx/Rx pinmux pins.

The pinmux settings for the UART2 are not explicitly set in the industrial I
    baseboard for the RS-485 expansion board.  Set them.

Signed-off-by: Michael Williamson <michael.williamson@criticallink.com>

... and more log stuff...

So it looks as if the kernel has been built as required, but UART2 does not seem to be working. Could you take a look at the code I sent earlier to see if I have done something wrong?

One comment: I am not entirely sure if the flag SER_RS485_USE_GPIO is (1<<5) (which I am using) or (1<<4)...

I am looking at pins on J504, based on the Industrial IO Board rev C documentation

Curiously, only pins 1,2,3,4,5,9 and 10 have solder showing ... that does not fit with the documentation.

I see traces on the back of the board going to 1,2,3,4 and 5 ... again does not fit with documentation as pin 4 is N/C

So I tried the simplest thing, echo "hello" to /dev/ttyS2 and looked at all the pins on J504 - the Rx line (pin 2 on J504) is toggling. This is shown on page 2 of the documentation as an input pin to the MityDSP module and is connected to UART2_RXD. I also ran my code looking at pin 2 and it is toggling along with my write() statements. But pin 1 on J504 which is TX_ENB is stuck at ground. A confusing situation - any ideas?

Hi Steven,

Let's make sure you are referencing the correct revision information for the board (it has been updated a few times since original publication).

Revision history and schematics for the Industrial I/O boards are available on this page.

Check the 80- number on your board and map it to the proper documents. I apologize for the confusion if there was a mismatch with your documentation on the hardware.

-Mike

My board is 80-000268RI-2B, S/N 132541. I looked at the appropriate document on the page you referenced, and while it is not the same document I was originally looking at, the pins and connectors are the same.

Ah,

I think I may see the problem. Those connectors are pinned (on our PCB) for use with a ribbon cable and a DB-9 IDC connector (like the one you are using for the console). So the pins are numbered 1-5 on 1 row and then 6-10 on the second row (6 across from 1, 5 across from 10). This was because originally we had RS-485 and RS-232 drivers directly on the board and we used the same adaptor cables as for the console port. Is this the issue (you are counting odds on row 1 and evens on row 2 like a standard IDC numbering you would expect)?

That should be documented better, I admit.

-Mike

Actually, I take that back. The pin out is illustrated in Figure 2 of the specification....

-Mike

OK, then it all makes sense. In spite of the way the connector is shown in the documentation I was assuming (never assume) that the pinout was the "normal" IDC connector pinout.

So we are left with the problem that the TX_ENB line (pin 1) is not toggling. I have modeled the code on the example 'send.c' code on the Wiki page "Driving_RS-485_transceivers", except that I replaced padding¹ with padding⁰ and GPIO3_9 (3*32+9) with GPIO0_9 (0*32+9). The code is transmitting on the Tx line, but the enable line is not toggling.

Solved the problem myself - it turns out that either SER_RS485_RTS_ON_SEND or SER_RS485_RTS_AFTER_SEND must be defined for the toggle to work. The flag SER_RS485_RTS_BEFORE_SEND is not recognised by the compiler, and (1<<3) doesn't seem to have any affect on TX_ENB. SER_RS485_RTS_ON_SEND makes the TX_ENB high when transmitting, and SER_RS485_RTS_AFTER_SEND is the opposite. I am seeing the line toggle about 9 microseconds before sending starts and about 50 microseconds after the end of the transmission - this is at 19.2 kBaud.

Thanks for the help in resolving this issue.