OpenMV IDE 1.9.0 "stopping" issue

I downloaded the new IDE, version 1.9.0, and sometimes when I click on the stop button (the red X), instead of stopping, the camera LEDs all turn on (white) and the IDE doesn’t respond. Eventually the OS reports that the device was removed. I’m on macOS High Sierra. Anyone else having any problems?

Hi, we updated the IDE software to add more timeouts for Mac. We found this to be the issue with the camera having problems. We wait 50 ms after the last polling command sent the camera on Mac to issue stop and 50 ms afterwards. Does this issue happen every time? Getting all white LEDs means a fatal error.

I get this problem fairly regularly. Hit the stop cross and I get a white light on my M7. OS sees the M7 as disconnected. Sometimes I get a corrupt SD card. I am assuming that the IDE exception that you get is interrupting a file IO operation hence the SD card corruption.
It would be nice if there were some way of of flagging to a script that a halt has been requested. Then the script could terminate gracefully under program control.
I am looking at attaching some switches to the M7 GPIO so that an ISR can set a flag that my scripts can use to terminate gracefully with. Instead of a while(True) statement I can then use a while().
Much nicer if this could be implemented in some way through the IDE
I am using IDE V1.9.0, OS is Linux (openSUSE Leap 42.2).

Things should be rather solid on linux… I haven’t tried on openSUSE however.

Can you create a bug for this on the openmv cam firmware page?

Also, can you share the firmware that causes the issue here? I’d like to test and see why.

Ooops! Bit of a drop off there. Firmware version is 2.9.0.

Great, can you share the script that’s having issues?

Ok. The code i am using is as below
Note that all the io is happening because i was tracking down why the image held in the allocated frame buffer was getting corrupted.
I suspect that one of the routines, such as find_blobs, is using the memory without checking to see if it is in use.
That is just a theory.
The code may not make a lot of sense as this is a snapshot of where I am in my current investigations.
The overall task is to detect movement and to save a clean image of the frame where movement was detected.
I found in my use case your method of using percentiles did not work very well

import sensor, image, time

PixelsThreshold = 250
IntensityThreshold = [(50, 255)]
LastImageFile = "LastImage.bmp"
LastDifferenceFile = "DifferenceImage.bmp"

# Pretty standard start up code
sensor.reset() # Initialize the camera sensor.
sensor.set_pixformat(sensor.RGB565) # or sensor.GRAYSCALE
sensor.set_framesize(sensor.QVGA) # or sensor.QQVGA (or others)
sensor.set_auto_whitebal(False) # Turn off white balance.
sensor.skip_frames(time = 2000) # Let new settings take affect.
clock = time.clock() # Tracks FPS.

# Special case of the first frame where there is no previous frame to work with
firstFrame = True

thisImage = None
tmpImage = sensor.alloc_extra_fb(sensor.width(), sensor.height(), sensor.RGB565)


    if firstFrame:
        firstFrame = False

    thisImage = sensor.snapshot()"thisImage.bmp")

    blobs = tmpImage.find_blobs(IntensityThreshold, pixels_threshold = PixelsThreshold)

    for blob in blobs:

    print(clock.fps(), len(blobs))

    # Image no longer available in colour after this point

Hi, we just got a bug report of a pointer possibly not being checked in our list code from another user and this causing an issue. The problem is like in find blobs. The weird thing is… This issue would have been in the firmware for years now and yet the method appears to work still.

Anyway, I’m at Maker Faire today and this weekend but I can get this fixed if it’s and issue with find blobs. Ibrahim may jump in if he can.

Hi, Ibrahim is working on this issue and will release a patch firmware. We previously fixed this issue before a long time ago but it appears to have come back again when we updated MicroPython.

Quick work good response, looking forward to the patch firmware

I don’t get this every time. Actually, today was going pretty well but the IDE wasn’t recognizing the camera and I created a new file and ran it when all the LEDs came on again. So, I don’t think it is related to find_blobs in my case.

In fact, I saved the default “new” file and was able to get it to fail on the first time of resetting the camera and running it.


  1. connect camera in IDE
  2. create new file
  3. save script to camera, stripping new lines
  4. reset camera via menu in IDE
  5. re-connect camera via menu in IDE
  6. run script in IDE
  7. stop script in IDE

At this point all the LEDs turned on and the camera eventually disconnected from the OS.

Another question: was there a change that made all the LEDs flash when hitting stop (even when successful)? I never noticed this before.

I was playing around with a script that was just using the LEDs and the fatal error never happened. But only after 3 starts and stops with the default “new file” script it happened.


Can you test the attached firmware ? It should fix the stop issue.

Note: Yes I think I changed the LEDs reset recently (it’s okay). (1.09 MB)

I tried it but still got a fatal error. Here are the steps:

  1. Ran bootloader
  2. Created new file
  3. Ran script
  4. Stopped script
  5. Ran script
  6. Stopped script
  7. Reset camera
  8. Un- then Re-plugged USB
  9. Connected
  10. Ran script
  11. Stopped script
    Fatal error

By fatal error do you mean the camera restarts or gets stuck in a loop ? The issue I was seeing is random stop/exec cause the camera to hardfault and restart.

What’s the status on all of this?

I’m waiting for MP developers to confirm the fix, see: