Can you record a stream with one script, load it with the other, and if it crashes attach the stream here ? I just want to replicate the exact same setup you have. In the meantime Iām trying the script again and checking for other issues.
import sensor
import image
import time
import pyb
# Number of frames to pre-allocate and record
N_FRAMES = 950
sensor.reset()
sensor.set_pixformat(sensor.GRAYSCALE)
sensor.set_framesize(sensor.HQQQVGA) #resolution
sensor.set_windowing([3,13,57,24])
sensor.set_auto_exposure(False, exposure_us = 2700)
sensor.set_framebuffers(3)
sensor.skip_frames(100)
clock = time.clock()
# Write to memory stream
#stream = image.ImageIO((57, 24, sensor.GRAYSCALE), N_FRAMES)
stream_out = image.ImageIO("Test_file_1.bin", "w")
for i in range(0, N_FRAMES):
clock.tick()
# stream.write(sensor.snapshot())
stream_out.write(sensor.snapshot())
print(clock.fps())
print("DONE Recording")
pyb.delay(2000)
stream_out.close()
Crashed reproduced with:
import image
import time
import pyb
# Number of frames to pre-allocate and record
N_FRAMES = 950
while True:
# Rewind stream and play back
stream_in=image.ImageIO("Test_file_1.bin", "w")
stream_in.seek(0)
for i in range(0, N_FRAMES):
print("Playing Frame" , i)
# img = stream.read(copy_to_fb=False, pause=False)
img = stream_in.read(copy_to_fb=False, pause=False, loop=False)
median1 = img.get_statistics(roi=[36,0,21,4]).median()
median2 = img.get_statistics(roi=[2,0,4,5]).median()
stdev1 = img.get_statistics(roi=[35,0,9,18]).stdev()
stdev2 = img.get_statistics(roi=[30,0,27,14]).stdev()
print(median1)
# Do machine vision algorithms on the image here.
stream_in.close()
print("DONE Looping")
With looping from .bin I sometimes manage to get through 1 loop of 950 whereas when looping from SDRAM it always crashes during first loop.
Typically I always use SD card. This time given it was a 1 off recording , although signifcantly slower I used flash because SD card is in the other room.
Thatās good, letās keep using the flash we donāt want to introduce another variable. Iāve made a small change to the script to print the iteration, and itās going through the 10th playback, with no crash. I will keep testing this and get back to you. Thereās another issue with USB/CDC/text buffer that might be related, so will try to fix that first.
I tested with different boards and I donāt get the problem.
Only diffrerence is that the SPI isnāt wired on those.
I will proceed to try to keep the master processor (the one that sends out SPI commands) reset whilst running the openmv script. In theory I have been testing with no messages going out from the master but it may be that anyway somehow it is interacting.
With new dev release (firmware and ide) I got through 1 loop and then after crash.
I think maybe print buffer on ide may be different so I wouldnāt make much of that.
Will report shortly on test isolating the master processor. I cannot physically disconnect SPI connections but I can put the processor in permanent reset.
With Master Processor (SPI Master) in reset script still crashes. Not sure what state the OMV pins are when in reset state.
The SPI pins are routed on my pcb together I cannot disconenct them.
Can I get the Openmv to ignore those Pins somehow in the script I provided to try to isolate?
Maybe has nothing to do with that but trying to replicate identical situation .
Played around with new dev release. I managed more than once to get through 2 to 3 loops. Something improved with last dev release. With prior dev release crashed always on first loop. On 4.5.8 never crashed.
I often get the error:
AttributeError: āstrā object has no attribute āmedianā
No, but thereās an SDRAM self-test thatās enabled by default, but by default it runs in quick mode. You can change it to exhaustive mode by setting this to true in main.c
Iām still not setup to compile firmware (on my todo list). Could you provide me a build? I donāt know your opinion but I think this might very well be the reason that somehow is masked with 4.5.8 and prior releases. Where are the faults logged after the test?
Yes but I need to fix something first before I can send you a firmware image. In the meantime, if you think itās a hardware issue, you should try a different board. This is not a custom board right ?
I thried other openmv boards and cannot replicate crash.
The boards in my product have exact same components and layout of the openmv board and have been using for 3 years. I needed custom to integrate all electronics on one board for my product.
This particular board has been in a prototype since 1 year and never had issues.
I will test another custom board and see if issue persists.
Questions:
Is it possible to have a build where I can set a flag to turn off whatever is being done differenty from 4.5.8 in terms of memory management? Would that make sense?
Can we also have an option to turn DMA off? The no DMA build effectively made such that there were no crahes.
Is the loew camera sensor performance understood or should I expect lower perfromance in the next releases?
If there are damaged SDRAM memory sectors , which can happen , does the firmware cope dynamicaly or would one have to specify in the firmware to skip some memory regions (assuming they are identifiable)
You should have mentioned that this is custom board. While we support our products, we donāt have the resources to support yours as well. We canāt possibly know whatās wrong with your hardware or how recent firmware changes may have affected it.
I doubt that as we normally donāt share the layout for high-end boards, and if your layout is different, it might affect SDRAM timings.
No that doesnāt make any sense. There were about 300+ changes since release 4.5.5 that span a 3 repositories, may as well just use the older firmware.
Youāre getting crashes on a script that doesnāt use SPI at all so Iām not sure how disabling SPI DMA will help, but we canāt add this anyway.
The performance will be restored for sure. As for SDRAM, I donāt think a PC can do that let alone a microcontroller with a single-chip DRAM.
I do see a different bug now in the dev firmware, but itās been there after the stable release, so itās unlikely that itās affecting you, but will be fixing it anyway.
I wrote a script to check all SDRAM memory sectors. Script was crashing on my boards but not on openmv boards. I introduced delays to try to capture failures. The script ran to completion on the entire memory and didnāt find any faults.
I went back to our script to reproduce the failure and introduced a delay after getting statistics
1ms ā crashing
100ms ā not crashing
50 ms ā crashing
Seems like something with the timing. Indeed related to my boards. I cannot work with delays greater than 1 ms in that loop .
Do you have reccomednations ?
Can you pinpoint what change between 4.5.5 and dev release is causing this behavior now?
I wouldnāt suspect RAM because that is part of the chip but SDRAM is an external periphial and the impedance of the connections on my boards might be slightly different then yours thus maybe more sensitive to timing.
Is it possile to change the working freq of SDRAM via python script?