PWM on pins, i.MX6, UDOO Quad, UDOObuntu?

I'm writing an application and would like to connect the internal PWM module to one of the PWM pins on the i.MX6. Can someone point me to a resource that explains how to do that? (My application is written in Python, but I don't suppose that that is relevant.)

UDOO Quad, UDOObuntu

Thanks!

 

Hi, you have to recompile the kernel, enabling PWM output; i think the file that you need is:
/arch/arm/mach-mx6/board-mx6dq_seco_UDOO.h
Looking at the udoo pinout diagram
http://udoo.org/download/files/pinout/U ... iagram.pdf
you can choose your alternative pinmuxing.
Hope it helps.

 

REALLY!?

Is this the only option? Sounds like a bit of an excessive requirement for something so basic.

 

You mean to say that PWM isn't basic functionality, and expected output, of a chip? I disagree.

 

You can do basic PWM control (no interrupts) without a kernel recompile by poking the registers directly.

Grab Freescale's reference manual for the i.MX6 chip, "IMX6DQRM.pdf" (just Google for that filename), which weighs in at 52MB and 5827 pages. Sections of interest are Chapter 4, covering pin-muxing control, and Ch. 51 describing the PWM outputs.

There is a command-line tool called "devregs," developed for another company's board but usable on the Udoo, that allows reading and writing chip registers from the command line (via /dev/mem). This can be obtained from

https://github.com/boundarydevices/imx-utils

Besides the program itself you'll need the data file "devregs_imx6x.dat", which should be copied into /etc

Beware that running devregs with no arguments, which is supposed to print out the full contents of all registers, will crash the CPU, requiring a hard reset to recover! Maybe there's a register somewhere that causes side effects when read? I patched my copy not to allow this.

Anyway, a quick test using the pin marked "PWM7" on Udoo board's headers (by Arduino numbering), which is normally gpio42 on the Linux i.MX6 side but can be switched to PWM4:

Code:

# devregs IOMUXC_SW_MUX_CTL_PAD_SD4_DAT2
  should return "0x00000005" ==> ALT5 pin mode == GPIO

# devregs IOMUXC_SW_MUX_CTL_PAD_SD4_DAT2 2      # change pinmux mode to PWM4_OUT

# devregs PWM4_PWMCR 0x0003fff0   # clocksource = 32kHz, div by 4096 = 8 Hz
# devregs PWM4_PWMPR 6            # set period (6 + 2 = 8 cycles)
# devregs PWM4_PWMSAR 1          # set duty cycle to 1/8
# devregs PWM4_PWMCR 0x0003fff1   # enable PWM output

On my board that 32kHz oscillator seems to be a bit off, since this strobes faster than the expected 1 Hz, and in brief testing I couldn't get the higher frequency clock sources to work... those might be dormant by default as a power-saving measure, and need to first be configured using separate registers.

 

can you please explain what "no interrupts" do you mean..

 

The i.MX6 PWM controller has a small sample buffer for varying its period / duty-cycle automatically, and can signal an interrupt when it's nearly empty, kind of like the output side of a sound card. This could be used for waveform synthesis and other interesting things, but would require a proper device driver in the kernel, not just poking at registers from userland.

This facility isn't needed for simpler, Arduino-style PWM use, though, where you set a frequency and duty cycle and just have the chip generate that continuously until it's next updated.

 

Hi, I am trying to get PWM working on i.MX6 as well, could anyone give me a more detailed instructions on how to get the devregs tool working?
Thanks a lot!

 

In the attached ZIP is a precompiled binary of the 'devregs' tool (my slightly patched version that avoids the print-all-registers crash-- beware that reading certain registers can still crash the Udoo! I'm not sure why. Careless register writes are obviously dangerous too). Drop the .dat file in /etc, then chmod +x the binary and move it to a directory in your $PATH. It must be run as root, via sudo or equivalent.

This was compiled for Debian. It may not work on Udoobuntu or other distributions without a recompile, due to possible shared-library differences.

 

Hi fetcher,

Thanks for the 'devregs' binary. I get this error when I run it:

-bash: ./devregs: No such file or directory

I am running Ubuntu 12.04. Is this the problem?

Thanks

 

Try 'chmod +x devregs' after unzipping, in case the executable bit got reset by your unzip tool.

If that doesn't help, there may be a shared-library incompatibility between your Ubuntu system and the Debian distribution I built this on.
To check for that, after unzipping run 'ldd ./devregs' on the binary -- output should be

Code:

        libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0x2acf6000)
        libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0x2ac48000)
        libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0x2ab51000)
        libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0x2ada0000)
        /lib/ld-linux-armhf.so.3 (0x2ab30000)

If any of the lines say "not found" instead, you can try symlinking a similarly-named library to the path it wants, do 'ldconfig -v' and try again, which may or may not work (remove the link if it doesn't) , but chances are you'd need to compile it yourself from the Boundary Devices source.

 

I actually got it to work by recompiling it. Now my problem is the pwm signal is very dirty. How did you get it to be clean?

 

What do you mean by dirty? Full of analog noise? If you're checking it on an oscilloscope, is your probe grounded to the Udoo GND?

Is the corresponding Arduino signal sharing that pin definitely set as an INPUT? If you're not using the SAM3X at all, try holding it in reset by putting a jumper on J16 (near MicroUSB connectors at the rear).

I didn't notice any such problem, but have only tried driving LEDs so far, which wouldn't be bothered by noise.

 

I am experiencing the same noise this blogger experienced:

https://www.google.com/url?sa=t&rct=j&q ... EDCuXBVN7g

However, I wasn't able to get any signal following her workaround.

I was however, able to get a clean pwm signal when I enable my ethernet interface. That must have changed some timer settings. I will play around with it.

Thanks

 

To clarify, by "enabling my ethernet interface" I meant I ran this command:

dhclient eth6

 

Ah, interesting. I wonder if there's some unwanted pin-mux interaction between Ethernet MII signals and i.MX PWM, like what I just found between I2C_0 (bus 1) and UART 2's RTS/CTS interrupt... the right register change could probably fix it if so. I've never run an Udoo without Ethernet active, though, and so didn't notice this during earlier tests.

 

Actually setting STOPEN, DOZEN, and WAITEN bits of PWM4_PWMCR fixed it for me.

Thanks

 

Hi fetcher,

Have you ever tried the high freq clock input for the pwm? Do you know what the frequency is for that?

Thanks

 

I found that I had to enable the clock settings for pwm4 in CCM_CCGR4 for the hi-res clock to work.