Motor and LCD Shield conflicting

If I initialize the LCD shield and try to do PWM with the motor shield as well, it behaves strangely running one of the motors at what seems to be full speed. Are there any conflicting pins? How can I fix this?



Yes the motor and LCD shields have common pins, you can’t use them both at the same time.

Is there any workaround? I know there are other free pins I could use for the motor shield PWM and direction than are used by the LCD, just not sure if there are enough.

No, unfortunately the LCD shields needs a lot of pins most of which are shared with the motor shields, and it leaves only 1 free PWM channel.

There is a workaround if you don’t mind adding more hardware. Connect the LCD shield to the camera and use a couple of the unused pins from the camera to send commands to an Arduino Nano or UNO and have it drive the motor(s). For example, P4 and P5 are free and they are serial (UART) pins, so you can send PWM numbers to the Arduino and have it interpret them and drive the motor. I am using a 4 line LCD display connected to an Arduino Mega to display status updates from the H7 camera. I use a serial link.

Hi there, I’m Cat and working with Ana on the same project.

I found that the debug connector has 2 pins that can be used as GPIO (PA13, PA14 on SWCLK and SWDIO).
Also, there are some un-soldered pins (24, 25) that are TIM2_Ch2/3 or something like that so I could use for PWM if somehow I can solder to them.
I think the current timer used is Tim4 so there should be no conflict

Which file(s) do I need to modify to give micro-pithon access to those? Can you do it? Others would benefit without negative impact.
It would take me a while to set the IDE and compiler up.

Thanks and best,


Me and Ibrahim have like zero time to focus on small adds like this. We really need our users to support the open source project but sending in commits to enable things like this.

As for the GPIOs to enable these… Um, it’s not that easy. Direct HAL access is easy but MicroPython has a lot of code layers on this stuff making it not straight forward. I’d recommend using another Microcontroller for I/O that you just talk serial to the OpenMV Cam with. This will be faster.

I’m confused: it’s a small add but you don’t have time for it?

And it’s small but with many code layers? And you can’t even tell me which files I need to edit?

I want to use your OpenMV in a product. If I add another uC it increases the cost a lot; it’s not an option.

I bought it because, among other things it had the LCD and motor shields. I didn’t see anywhere they don’t work together.
I found which pins can be used so you; knowing your product/code; could enable them in, probably, less than an hour.

Please do.


Hi Cat, I have a day job and don’t get much time to actually write code anymore because I have to answer various help support emails along with other things in my time to run the OpenMV project. Depending on me to modify the firmware to support this type of stuff was fine when the project started but generally it gets stalled now since I’m too busy.

As for the files to modify. I don’t actually know exactly. Ibrahim deals with the MicroPython base code. I wrote a lot of the image processing code and that’s where I have more experience.

I’ll ping Ibrahim and see if he can do something for you. He’s in the middle of moving right now however…

Note that the STM32 registers are directly accessible via python using the stm module.

You can so:

import stm

stm.mem32[0x…] = …

To directly set a register in RAM. Using this you can do direct GPIO control by looking up the correct registers in the STM32H7 reference manual.

Doing anything more than GPIO control is probably too complex however beyond this.

Mmm, this file might be it:

It’s in the MicroPython submodule in the main firmware. Adding the new pins to it should create the Python parts when you do a rebuild of the firmware.

You can find the build instructions under the wiki on the OpenMV firmware GitHub.

I bought it because, among other things it had the LCD and motor shields. I didn’t see anywhere they don’t work together.

The pin mappings of every shield is in the product page, we have a limited number of I/Os it makes sense that some shields will share pins. However we’ll make sure this info is mentioned.

I found that the debug connector has 2 pins that can be used as GPIO (PA13, PA14 on SWCLK and SWDIO).

I think SWCLK and SWDIO have some limitations on being used as GPIOs, you have to check the datasheet first.

I want to use your OpenMV in a product. If I add another uC it increases the cost a lot; it’s not an option.

If you’re just doing a prototype for a product, you could use another micro-controller/chip to control the motors as it will not be part of your final product. Plus any changes made to enable pins will not be merged in the upstream firmware.

Alternatively, you could try something like this, it’s a serial (“smart”) LCD, it will be much slower but it should free a lot of pins.

This is not great.

  1. The project seemed to have good support. New HW, etc. I didn’t read anywhere that support is going down because of a day job. It’s understandable but it should have been mentioned.

  2. It’s nice that registers can be set but setting up a timer by doing that seems like a big pain. Much bigger than re-doing what’s already been done in source code, by somebody that’s done it already for other pins/timer. OR at least say where.

  3. RE “pins.csv”: iabdalkader should be able to tell me if it would be enough to add lines there for P10-13 with PA13, PA14 etc. I suspect it’s not. What else?

  4. You say “Plus any changes made to enable pins will not be merged in the upstream firmware.” I think any changes YOU make could and should make it.
    Why not? They wouldn’t break anything.
    And, you could add some Test-Points to some/most unused pins to make it easier for them to be used by anybody that doesn’t have enough pins.

5, I think it’s wrong to add new/different HW and have to write new code for another display when existing HW is totally capable of doing what’s needed, if only one could do a little more of what he’s done already: You already did set PWM up on some pins so it should be trivial to add that to other pins AND keep it there. And the GPIO either on the pins I mentioned or other unused pins.



Hi Cat, I’ll sit down and try to get you a firmware image tonight with new GPIO pins added.

A question however, I’ve never used any other product where I got support tickets answered the day of by the creator and feature requests considered. I don’t understand your expectation that your request would be serviced at all. By all accounts we should stop responding to you and not help you given your attitude.

For example, if I ask for something on MicroPython Damien is generally too busy to answer timely or really do anything other than make a simple suggestion.

Similarly, if I asked something on Arduino’s forum Banzi would never answer it.

K, I’ll added support for the GPIOs and leave notes here on what I did to do it. I think I should be able to add more PWM too and I’ll add notes for that too. It’s all changes to MP code so it shouldn’t be too hard. They autogenerate a lot of stuff and there’s no documentation on it… So, I just have to figure it out.

I appreciate it.
I didn’t expect support same day.
But I did expect support, as I saw support being given in the past and that was a big plus.
There are cheaper cameras out there with more powerful processors but I chose yours because it seemed you’re “close”, I don’t know how to say this.
I think my attitude started nice enough; I agree it didn’t stay that way but I think you may see why.

Thanks again,


Please understand I answer most of these support questions on my phone during work. I’m not in font of my OpenMV development computer. This limits what I can respond with.





Makes the new pins available. You can toggle them and whatever now.

This also enabled you to use timer 5 for PWM on pins PA0/1/2/3:

# PWM Control Example
# This example shows how to do PWM with your OpenMV Cam.

import time
from pyb import Pin, Timer

tim = Timer(5, freq=1000) # Frequency in Hz
# Generate a 1KHz square wave on TIM4 with 50% and 75% duty cycles on channels 1 and 2, respectively.
ch1 =, Timer.PWM, pin=Pin("P13"), pulse_width_percent=50)
ch2 =, Timer.PWM, pin=Pin("P14"), pulse_width_percent=75)
ch3 =, Timer.PWM, pin=Pin("P15"), pulse_width_percent=75)
ch4 =, Timer.PWM, pin=Pin("P16"), pulse_width_percent=75)

while (True):

Finally, I updated the servo code:

To support 4 servo channels - i.e. PD15 (P10).

# Servo Control Example
# This example shows how to use your OpenMV Cam to control servos.

import time
from pyb import Servo

s1 = Servo(1) # P7
s2 = Servo(4) # P8

    for i in range(1000):
        s1.pulse_width(1000 + i)
        s2.pulse_width(1999 - i)
    for i in range(1000):
        s1.pulse_width(1999 - i)
        s2.pulse_width(1000 + i)

Ibrahim may wish to roll these changes into the default release so that they are just there.

To load the firmware just (while not connected to the camera) do Tools → Run Bootloader and select the firmware.bin file. The file is for the H7. (971 KB)

Thank you very much; I’ll try these.


Was it enough to add the pins to the CSV to get all Alternate Functionality?
That seems amazing.
How did it choose TIM5 for PWM when it could have chosen Tim2?

Thanks again,