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

Hi Conor,

I don't see anything wrong with your approach. You might check the value that the pin is reading back (e.g., cat /sys/class/gpio7/value). If the pin is stuck, it should right a "1" in all cases. If it is toggling, then perhaps you are looking at the wrong pin or something. Or, the pinmux setting is somehow not correct or getting applied.

Are you using an Industrial I/O board for your test? Did you load up the latest kernel, or are you running with the 2.6.34-rc1 kernel that came pre-loaded in NOR Flash? The older kernel may not have the GPIO pin-mux code in it. We don't alter our factory images very often as most of our customers change the kernel for their specific applications. That may be the problem. Can you do a "uname -a" or capture the boot load or "dmesg" text?

-Mike

Thanks Mike,

When I cat from /sys/class/gpio7/value, it reads "1" all the time, no matter what I've previously written. I did think that I was reading from the wrong pin so I had checked that...

1. uname -a
   Linux mityomapl138 3.2.0+ #2 PREEMPT Wed Aug 22 10:42:06 IST 2012 armv5tejl unknown

If I load the debugfs driver and cat /sys/kernel/debug/gpio I get:
-----
root@mityomapl138:/sys/kernel/debug# cat gpio
GPIOs 0-31, DaVinci:
gpio-8 (DSD1791 CS
) out hi

GPIOs 32-63, DaVinci:
gpio-47 (CAN CS
) out hi

GPIOs 64-95, DaVinci:
gpio-64 (MMC CD
) in hi
gpio-65 (MMC WP
) in hi
gpio-94 (SYSTEM RESET
) out hi

GPIOs 96-127, DaVinci:

GPIOs 128-143, DaVinci:
---

which is the defaults for the board... I have not updated u-boot however. I'll try some other GPIO pins now and see what they do....

GPIO0/15 is the opposite which is rather odd. It starts out as 0, whereas GPIO0/7 starts out as 1:

root@mityomapl138:/sys/class/gpio# cat gpio15/value
0
root@mityomapl138:/sys/class/gpio# echo "out" > gpio15/direction
root@mityomapl138:/sys/class/gpio# cat gpio15/direction
out
root@mityomapl138:/sys/class/gpio# echo "1" > gpio15/value
root@mityomapl138:/sys/class/gpio# cat gpio15/value
0

Hmmm...

Do you have an expansion board plugged in right now? Can you disconnect it if you do?

It's possible that the outputs might not match the inputs if there is an external driver or short that is stronger than the driver in the OMAP-L138. The "cat" is reading the state at the pin, not the output driver setting.

I can try to reproduce here, but we may not be able to get to looking at this today. I haven't seen this problem (and we've used those GPIOs on several jobs), but I won't rule out a software problem until I can see it work here as you are running it.

Can you post the motherboard PCB number?

-Mike

Certainly... The PCB number is "120540". I've no boards plugged in at all - just the L138 module and the baseboard. There's only a single wire pushed into the connector which is connected to a voltmeter.

I'll try another one.....

OH! Weird! Gpio0⁶ (pin 22 of J700) works perfectly. When I set direction to "out", the meter dropped to 0V. Now echoing "1" sets value correctly and the meter reads 3.24V. echoing "0" sets to 0.00V.

That's supposed to be GPIO0/6 by the way...

I cannot find any particular reason for the pins to do this in the code. I'll recompile the kernel and uboot on the off chance something is happening there... I never updated uboot and I believe some gpio pin parameters are set there too.

I took the MDK from 2012-03-12 and compiled uBoot and uImage from defaults (using industrialio-defconfig for the kernel). I then flashed those to the board and it booted up just fine. But GPIO0/7 will still not toggle. It will change gpio direction from 'in' to 'out' but nothing else. On the other hand, GPIO0/6 works fine as an output and as an input.

I may be able to shift my board design to use GPIO0/6. I can cut a track and patch from Gpio0/7 to gpio0/6 but it would be nice to know what's wrong. Is it possible I may have a damaged board? Some sort of short to +Vcc from the GPIO pin?

Thanks, Conor.

Hi Conor,

Think I found it. If you check the schematics from this page, it looks like GP0_7 is pin-muxed for the AXR15 (done in the baseboard_Setup_mcasp() function) on all boards since Revision 80-000268RI-1C, when we started to support FPGA-less modules. That was some time ago. Very few of our customers should have revisions older than this (we only built a handful for select customers). Can you please check if you are using a newer board and confirm the schematics are consistent with your design?

I am sorry for the confusion. The industrial I/O unfortunately went through a couple of modifications early in the life cycle of the product and has at times created some of these issues. Hopefully this explains the problem.

-Mike

My board is rev: 80-000268RI-2B, the latest revision.

Ah yes. I see. I really should have spotted it myself as I went and checked GP0⁷ in the L138 docs and saw that it was multiplexed with PWM and mcASP functionality. But as GP0⁶ was also muxed with mcASP I discarded that theory figuring it couldn't be that. I didn't see the DA850_AXR_15 in the setup_mcasp and probably wouldn't have made the connection there anyway - the kernel really is a maze of twisty passages.

Once I know what to look for (grep for DA850_AXR_15) it suddenly becomes obvious I guess !! Finding Gp0¹⁵ is similar - it's multiplexed with ACLK_R and I can see that DA850_ACLKR is also used in the baseboard_mcasp_pins[] array. Similarly Gp0¹³ is DA850_AFSR.

I cannot see that the ASP is connected to anything so I can probably just comment out "baseboard_setup_mcasp()" in baseboard_init() and that might do it (fingers crossed).

By the way the circuit diagram shows big red Xs over the MMCSD0 pins on J700. Does that mean they aren't actually connected? Or just that the 33R resistors have been removed?

Many thanks for finding that out for me. I would have been slightly hosed otherwise. I'll do up a Mux document at some point!

Cheers,

Conor.

It works! Thanks for all your help on this Mike. I really appreciate that.

Big Note: It still does not work on Gpio0/7. Because gpio0/7 is not actually routed to the J700 connector!!!

Look at the links for the latest rev of the board at http://support.criticallink.com/redmine/projects/indio/wiki/Industrial_IO_Revision_Information. The datasheet is out of sync with the schematic. The datasheet shows GPIO0/7 being routed to pin 19 of J700. The schematic shows GPIO0/5. When I toggled gpio5, the pins toggle correctly and the meter shows the right answer.

This would still have been an issue as I needed pins like GPIO0/13 which were indeed being muxed with mcasp so I'm still good here!

Conor.