Running program without the IDE - upload, reset, no-go

Subject says it all. I’ve uploaded my script, I’ve confirmed that the file has been updated on the OpenMV side, I’ve reset the camera and nothing happens. My program works without issue when running through the IDE. I’ve taken a look through the threads on this topic, but all seemed to have been resolved by following the upload/reset instructions. Any ideas what might be wrong?


I confirmed the issue with a very simple file:

# Untitled - By: cphelan - Mon Oct 29 2018

import sensor, image, time, pyb
from pyb import delay

uart = pyb.UART(1, 115200, timeout_char = 1000) #pin 0 = RX, pin 1 = TX

    uart.write ("test")

What do I need to do to get this running standalone?

Tools->Save open script to OpenMV cam.

Thanks, but I’ve already done this. My quote above “I’ve uploaded my script, I’ve confirmed that the file has been updated on the OpenMV side, I’ve reset the camera and nothing happens.” means:

Tools->Save open script to OpenMV cam
Tools->Reset OpenMV cam
Navigate to the USB drive hosted by the OpenMV cam and confirm that the file on the drive has been updated (check date)

Sorry that this wasn’t clear. What am I doing wrong?

Hi, we don’t support UART1.

Please move it to UART 3.

Thanks, but I’m using an OpenMV Cam M7. If I follow that link, it states the following:

UART 3 RX → P5 (PB11)
UART 3 TX → P4 (PB10)
UART 1 RX → P0 (PB15) (OpenMV Cam M7 Only)
UART 1 TX → P1 (PB14) (OpenMV Cam M7 Only)

Which is further supported by the pinout provided on this page:

Obviously I feel a bit silly telling you this as one of the creators. So, given this documentation, can I not use UART1?

Furthermore, I’ve tested/confirmed that UART1 works, at least when using the IDE.

Please let me know when you have a moment



I’ve actually been having a very similar problem.

Hmmm, this is a valid problem. Um, Ibrahim can you figure out what’s wrong?

Please note that the OpenMV Cam is kinda like a giant open-source feature creep software system. The bugs are in the system because we keep adding functionality and releasing firmware updates… and then when we update MicroPython things break.

I’ll look into it, we’re about to do a new firmware release anyway, if there’s a bug it will be fixed very soon.

Thanks guys, really appreciate it! Some clarification questions:

  1. Is it okay to proceed with using UART1?
  2. Is standalone operation impacted because I am using UART1? In other words, if I shift to UART3, do you expect that standalone operation will begin functioning? Note that I will independently test with some simple program - flashing an LED or something similar - on my side shortly.
  3. When do you expect to release new firmware solving this standalone bug? I’m using the OpenMV cam in a proof-of-concept device that needs to operate in a standalone manner, so given the answer to this, the above, and my schedule, I will need to figure out the best way to proceed.


Use UART3 if possible. UART1 might have been tested once during an MP upgrade and then ignored afterwards. UART3 is the only one I have code that I know works when in a script by itself.

Also, keep in mind that writes to the embedded file system sometimes are delayed unless you are using a flash card. This is because all OSes ABSOLUTELY REQUIRE you to safety unmount the OpenMV Cam after you write to it’s internal flash. I put some code into OpenMV IDE that tries to make sure things get flushed to the OpenMV Cam when you reset the camera… however, they only sometimes work.

(For the uninitiated… SD cards are FAT16/32 devices which all OSes flush writes to immediately. However, our internal upyFlash device on the OpenMV Cam when there’s no SD card is FAT12 which all OSes buffer writes on. FAT12 is decided by the disk size being smaller than 16 MB. So, it’s impossible to fix without having 16MB of flash. Due to the file-allocation-table requirement too you can’t fake 16MB either).

Hi, this script is running fine standalone (in Seems to be an issue with the IDE not flushing the writes before removing the disk. Please make sure the is actually written (not an empty file) and manually remove/umount the disk until this issue is fixed.

EDIT: You can use UART1 or UART3, they both work.


I was able to demonstrate that an OpenMV cam disconnected from my custom adapter PCB was able to run standalone, even using UART1. I then proceeded to swap the header orientation on this OpenMV cam (so I could connect to my custom PCB), and somehow managed to kill that OpenMV cam in the process. I attempted to reflash the firmware on that cam, but it is not recognized by the IDE - not sure what happened.

Upon plugging back in the OpenMV cam which was already connected to my custom adapter PCB, the IDE started re-flashing the firmware. Oops. But, once the re-flash was complete, it could run my basic LED flash/hello world program.

So, reflashing the OpenMV cam seems to have resolved the standalone operation issue. But the firmware version is still 3.0.0 (as it was before).

I still need to confirm that I can run my actual program standalone - but this is progress nonetheless.

Any ideas what may have caused this issue?


Mmm, could be some type of static shock might have broken something. I don’t have enough of a picture to say what’s wrong.

Sorry, by issue I was more curious about why re-flashing the firmware enabled standalone operation. I’ve written off the other OpenMV cam and ordered another - I’m sure that issue was due to user error.