fly-sht-36 support
Hi. I am trying to flash fly sht-36 toolboard from RatOS frontend, I followed the instruction (added jumper and reconnected toolboard), button Flash became green, but after pressing it and waiting, it just becomes green again...
39 Replies
Button "next" - is grayed out.
Or maybe the problem is - I did not connect 24v power to it yet?
Shouldn't be necessary if you use the V_USB jumper.
Which sht-36 version is that?
Because the 2.0 is not supported and won't work.
If its the v1, please post /var/log/ratos-configurator.log
(fetch it via something like WinSCP)
yep. some error is there indeed.
it is V1
Also I tried different usb cable, with same result.
Which jumper is it? I only added a jumper between boot0 and 3.3v
dmesg output:
I tried to flash manually by dfu-utils
note the:
BTW, my stm chip:
Everything is disconnected from the fly-sht36 except usb cable.
Okay. I have a clue.
When I flash from orange pi 3 lts by dfu-utils:
I receive error at the end:
But if I run the same command from my normal x86 PC, with same version of dfu-util 0.11, I don"t receive any error!
Will try to compile dfu-utils from source, maybe that is the source of magic...
Is the configurator updated?
Are you running RatOS on orange pi?
With the experimental image?
Should it be updated?
Yep
Yes
This is probably the issue
I have no idea what the state of that is, i suggest taking it up over in <#1075501089257963540>
Might be an issue with dfu-util for all i know
What and how should be updated?
Yep, probably indeed.
In mainsail, in the machine tab, make sure RatOS and RatOS configurator is up to date (basically just follow the manual)
Oh, btw, update of sht 36fails but firmware actually flashes fine
So if I remove jumper, ratos detects fly sht 36 and version of firmware without any issues
And you haven't flashed it before? Like you showed here: https://discord.com/channels/582187371529764864/1091764799769157743/1091835819897143477
Thank you, will post my problem there
I cleaned it after
How?
By dfu util erase
Ok.. Hmm
strange
It is not problem in RatOs for sure, some bug in dfu-util
On orangepi only apparently
It returns non successful exit code on complete, that makes klipper scripts to report error
Sorry, yep
Because it works on raspberry pi which is using the same manually compiled dfu util
It is problem of Orange Pi+dfu util
Maybe try using the one from apt
It's version 0.9 i think
Btw, tried to compile dfu-util from sources - did not help
that's done during image compilation
So you'd just get the same thing
I'd get rid of the current dfu-util installation and install it from apt
Thank you for suggestions!
And it works if I flash from my PC as I said 8)
yep, not sure why the manually compiled one doesn't work on orange-pi but hopefully the one from aptitude does
If I will find the solution/install of old dfu will help, I will post it there. Otherwise- thank you for you time!
excellent! đź‘Ť
It became weirder...
I added a 1 sec delay before status check in dfu source code, which have been throwing
no more error...
I would guess, orange pi takes enormous amount of time to initialize usb device?...
As software engineer I cannot accept such solution xD
and as expected, it works unreliable, after reboot it stopped working 8)
oh shit
two sequential calls to dfu-util without any changes:
Tried v0.8 and v0.9, same problem
so, this error message is just random, even with delay 8) Without it, errors are even more often
That sucks..
Update if some will step into same issue, for some reason with my mello-fly-sht-36, libusb fails to find device after reset as final stage, with LIBUSB_ERROR_NOT_FOUND, it is not critical and device seems to flash and reset fine, but drives crazy ratos update scripts, so as workaround, I patched dfu-util to ignore this particular error on reset. Ping me if you need the patch.
Modifying klipper/ratos scripts would be easier, but dfu-util seems to replace this particular error by some generic one when probagandates error code, and I don’t want to ignore some other possible error unexpectedly
Odd, as i don't have this problem with the fly-sht-42. Raspberry Pi though. So i'm assuming it's a problem with libusb on orange pi?
I had same results on x86 pc too
I guess I just have a little bugged fly-sht
Or maybe default firmware.cfg for my fly-sht in RatOS is not for my chip (some letters seems to be missing)
I have heard that mellow tend to use a little different stm32 chips in their fly-sht, don’t know how much true is it