I'm trying to recover my board after installing dudOS by mistake then trying to flash with a different firmware has caused this.. I have been trying for weeks now and getting no where. Actually your OS has caused this and rerally should be replacing my board , it doesnt state anywhere that once DUDos is flashed there is no way of going back o its original thats it your locked in and DUDOS physically takes over the device which is not right. its a

In order to improve the efficiency of communication, it is important to provide the following information when posting a message
【1】Describe the specific problem encountered, (e.g., SWC button not functioning correctly, parking sensors displaying abnormally, door information misplaced, TPMS values not updating, A/C status out of sync, A/C temperature units incorrect)
【2】Your vehicle's make, model, and year、Car Center Control Pictures
【3】3: To provide system information, Settings - About - long press the top left corner of the image - send us a screenshot of the popup message!
【4】For more information, read the top post on this board UIS8581A2H10/sharkl3 board and need technical details about its early USB download/calibration mode.

Confirmed USB details:

VID/PID: 1782:4d00
Interface: 0
Bulk IN: 0x85
Bulk OUT: 0x06
Packet size: 64 bytes
Product: Spreadtrum Gadget Serial

UART shows:

USB SERIAL CONFIGED
USB SERIAL PORT OPENED
usb read timeout

A previous successful attempt received:

BSL_REP_VER: "SPRD3"

and successfully uploaded fdl1-sign.bin to 0x5000.

Could you please answer these questions:

What exact USB transfer sequence does the DUDU flashing/recovery tool send after USB SERIAL CONFIGED?
Does it send this control request?
bmRequestType = 0x21
bRequest = 0x22
wValue = 0x0601
wIndex = 0
wLength = 0
After opening the USB serial port, should the host send:
one raw 0x7e,
repeated 0x7e bytes,
a 64-byte 0x7e buffer,
or a complete framed BSL command?
Does this U-Boot USB calibration port use the normal Spreadtrum HDLC/BSL protocol, or a different U-Boot-specific protocol before FDL1?
Is 1782:4d00 used for more than one internal boot state on UIS8581?
Does usb read timeout mean no USB payload reached U-Boot, or that U-Boot received an invalid payload?
Is there a required delay between the control request and the first bulk OUT transfer?
Does the host need to set USB line coding, DTR/RTS, configuration 1, or another control request before sending the handshake?
Is there a UART command, environment variable, reboot mode, or boot flag that forces or extends USB calibration/download mode?
How does the official DUDU recovery/updater hold this board in download mode without a boot key or test point?
Can you provide a USB capture, source snippet, or hex dump of the first control request and first few OUT/IN transfers from a successful connection?