Issues after migrating from stock firmware

[positron96]

Hi. This weekend I've flashed OpenDSO150 to my scope and, after struggling with display rotation (#44) have a working device. There are severe issues that I am having at the moment. I am posting them all as one issue for the time being, because there is a possibility that I am missing some small but important step during setup and all the issues might be resolved with one action.

1. I cannot boot without holding OK button. If I boot without pressing OK button, the program hangs somewhere on C++ DSO screen (in printConfig, to be precise). Does the program stores settings if it resets them, or do I need to save them manually?
2. Analog readings are completely broken:
   • zero values are not at zero: if I short + and - probes, I get the reading equal to my voltage scale (at 1V I get readings around 0.96V, at 5V somewhere around 5.2V etc).
   • slopes are somewhat too smooth, but cannot compare it consistently with stock firmware.
3. Rotary encoder is inverted for timescale: if I turn CW, it decreases the time period. Is it supposed to work this way? Stock firmware had it the other way around.
4. It is also not reliable - sometimes it changes the value in opposite direction, sometimes does not change at all. It happens with all values, not only timescale.

So, is this known behavior? Can I fix it?

[michar71]

Hi,

The boot issue is strange . Don't see that on my unit. (After reprogramming you need to hold the OK key once at startup but after that it should be working.) The issue here might be that "most" STM32F103 have 128K of flash (Even if thee datasheet only talks about 64K...) so I'm using the full amount and the config is stored in page 124 - 127. If for some reason your Processor is not able to access the full 128K then that might be causing issue. Just a guess, I've never seen a STM32F0 with only 64K of FLASH. (I've lately seen a lot of fake STM32 circulating....But with those it's usually not even possible to program them via the debugger so that's probably not the issue) Would be interesting to know if the problem goes away after changing the FLASH page for settings from 127 to 63 in EEPROMCONFIG.h

The broken analog readings are probably because there is no valid calibration for the offsets. Go to the menu at he bottom and select AutoCal and follow the instructions on the screen.

The rotary encoder is a pain to get working as it is connected to the display data lines so while updating the display it's not possible out read out the encoder. And if you rotate it too fast you miss a step which leads to interpreting it going the other direction. No idea why they build it this way but haven't found a 100% reliable way to get this working...

Michael

[michar71]

Boot issue is still strange..... It's not:

• Overclocking
• Memory Issues
• Pointer issues
• Code issues …. Just "Random" hard crashes (not random because it always crashes at the same place even if I move the code sequence around)… So for example in a sequence like this: printf("\n"); printf("\n"); //<- Crashes here.... printf("\n");

Hard to explain. Commented out the code sequence during startup and fixed another one where it crashed on a malloc (not related to memory, just doesn't like the malloc there. Used a static buffer, removed the malloc call and it works...)

If you see any more of those issues flag them. I take it as another hint that it's a good idea to rewrite the whole thing ;-)

[positron96]

Thank you for the response! Yes, the device hangs somewhere on printf("\n"), which is very strange. What's even stranger, I was able to boot 1 time without hanging, but then it returned to hanging again (so, probably not flash-size related). The chip says STM32, not GD32, which are chineese clones (though I've heard of stm32-branded fakes)

I'll try to commence some testing on weekend. Meanwhile, could you elaborate more on what calibration is? Where is that menu? What needs to be done for calibration to be successful (short the probes? leave them floating?)

As for rotary encoder, it's interesting that I never had issues with stock firmware, no matter how I rotated it.

[michar71]

There's another place where it just hangs on a malloc(). Not out of memory just dies. That's why I eliminated stdlib from the whole project in case there is somewhere a mix-up between the different printf's but it's not that. And the fact that it's reproducible on different systems means it probably has nothing to do with overclocking or device differences or fake processors. Never seen a hard fault triggered like that....

For Ground Level calibration select the menu at the bottom (Where it says Serial) and rotate dial to select calibration. Then log-press the encoder button to start it. Input needs to be set to GND. That will recalibrate the ground-level reference which seems to vary a lot between different scopes....

Not sure how they get the rotary encoder working on the stock firmware. It uses the same data-lines as the display so while you refresh the display you cannot sense rotary movements. I'm using the interrupts for the lines and deactivate them while talking to the display. There is a massive amount of bouncing going on from the encoder so I ]'ve a table that only allows valid transitions. But sometimes it seems that one mechanical click does not represent a valid transition (Or skips over one...) Not sure how they solved that in the stock firmware but the standard approach to reading out an encoder does not work well even if it's just the encoder and no display update or scope stuff running. Somehow there's a better way but I haven't found it yet....

[positron96]

I've heard that those cheap rotary encoders have 20 pulses per rotation, but can have different number of "clicks", so it's reading pulses does not correspond to tactile clicks.

How long does updating the screen take? Is it possible to just read encoder pins after each screen update (or by timer if the screen isn't updated constantly when, e.g, on hold)? Maybe the reading won't affect screen refresh speed much. Then you can calculate encoder movement by indexing a simple quarature encoder matrix array. An issue of noise is still an issue though.

[positron96]

Hello. Here are the results of my testing:

• Autocalibration worked to some extent. After I performed it for the first time, zero went at zero, but there was a noticeable sine wave around zero (at every scale). After reboot I had to hold OK button (see below), the offsets went back to invalid values and I tried to perform calibration once again, but it completed immediately without any noticeable difference (offset remains). After that I could not calibrate.

• Still, I cannot boot without holding OK button. Without OK, the firmware reliably hangs at malloc in tft_printf("Storage Depth: %d Samples",(int16_t)NUM_SAMPLES); function call. Seems like a RAM configuration issue.

[michar71]

Hi,

Sure you have the latest code? In the banner() routine my latest checkin uses the following lines: char fw_ver[8];

... tft_setCursor(30, 80); tft_print((char )"Storage Depth: "); sprintf(fw_ver,"%d",NUM_SAMPLES); tft_setTextColor(ILI9341_YELLOW, ILI9341_BLACK); tft_print((char)fw_ver); tft_print((char *)" Samples"); ...

(Somehow using a local variable fixes the issue for me.... No idea why...I massively reduced the sample size and increased heap stack as a test and the issue was still there so it's not a simple "out of memory..." issue. Lately I'm having very strange issues in general with STM32 projects. I've code for USB that worked in the past, now it fails on CubeIDE (And fails on platformIO but in a different way...) Starting to wonder if there are compiler issues but then a lot more people would be screaming....

Ripple is unfortunately nothing that can be calibrated away (Just offset...). I've only seen that issue with external power supplies, not batteries. (Crappy filtering on the power input) so that could be your issue....

[positron96]

Apparently, my version is not the most recent. I'll test soon.

[positron96]

Wow, the last version really does not hang! Great job!

Also, calibration worked on second try for me. What I've noticed is that when coupling is not set to GND, the calibration process just finishes immediately without any effect. When I set it to GND, on first attempt it did the same, but on second try it finally did the job.

[positron96]

It might be my hardware, but the buttons and encoder are really unusable. Most of the time the buttons do not work (Does the device read buttons when "Sampling" string is shown? Buttons seem to conflict with this string, but not sure), encoder clicks to random direction, as I already reported. Also, repainting screen after button press seems kinda broken - after I stop pressing the the button and press another button, the value of first button changes after I press another button (as if the last redraw of screen was missed the last time I pressed the first button). There is also an issue with repainting data, i.e. old data is not cleared when next is plotted over (the mode is AUTO)

[danielebruneo]

It might be my hardware, but the buttons and encoder are really unusable. Most of the time the buttons do not work (Does the device read buttons when "Sampling" string is shown? Buttons seem to conflict with this string, but not sure), encoder clicks to random direction, as I already reported. Also, repainting screen after button press seems kinda broken - after I stop pressing the the button and press another button, the value of first button changes after I press another button (as if the last redraw of screen was missed the last time I pressed the first button). There is also an issue with repainting data, i.e. old data is not cleared when next is plotted over (the mode is AUTO)

Same thing for me. Everything beyond 2mS triggers Sampling that make the device really slow. Also screen is often not repainting, levaing a ghost trace.