Firmware upload issues

[gabonator]

If you are having troubles uploading firmware to your device, please share your experiences / tricks / success stories here. Do not forget to mention which device (LA104/DS203/DS213) and what OS you are using

Device	Windows 7	Windows 10	Linux	OSX	OSX M1
LA104	copy twice	?	dfuload	dfuload	impossible
DS203	?	?	?	dfuload	?
DS213	?	copy twice	?	dfuload	unknown

• On OSX it is impossible to upload new FW via copying new files to DFU drive, dfu load tool imitates the upload process as if it was done on Windows machine
• On Windows machine there was a trick to copy the same file twice: By first copying the file it copy process finishes very quickly. Wait until the device disconnects the filesystem, and copy the same file again. In my case (windows 7) this second copy freezes, but the OS is flashed correctly. Try copying with copy command or use some file manager (e.g. FAR). If it does not work, try on different machine
• On linux you can use dfuload tool as well
• New builds contain firmware CRC verification. In case the image is corruped after flashing, the device will show a warning message during startup

[RChadwick7]

Sorry it took so long to respond, but I finally had time to experiment. I've got Windows 8.1, with Teracopy installed.

If I copy a single .HEX file, with either Explorer, or TeraCopy, i get the .ERR. However, if I rename the .ERR to .HEX, it switches to .RDY

If I copy two files (The second being an empty junk.txt file) with Explorer, I get .RDY

If I copy two files (The second being an empty junk.txt file) with TeraCopy, I get .ERR. If I rename .ERR to .HEX, it switches to .RDY.

Also, while playing around, sometimes things would intermittently work. Sometimes, it just turned .RDY without issue.

Hope this helps someone.

[gabonator]

Thank you for reporting this. And even if you copy the file only once, nevertheless ERR suffix, is the firmware flashed? I mean - is the second step with renaming the suffix necessary?

[RChadwick7]

In the past, although I got the .ERR, it seemed the firmware was properly flashed. I just always felt nervous it wasn't flashed properly.

[RChadwick7]

Also, while I didn't experience it this time, in the past I noticed it wouldn't copy properly, and seem to hang an unusually long time. Perhaps copying two files might help this.

[DjangoReinhard]

Hi,
wanted to try your LA104 on a ds203 - building worked fine, but then I got confused, as I didn't have disk2-device (on my linux box). Thought something went wrong ...
... until I understood, that I had to replace "disk2" by the devicename of my dso :(
I then followed the instruction from dfuload and copied "system_la104.hex" which worked fine.
Then I thought, I was done and turned of the dso.
Now I only have a white sceen after turning dso on.

Is there a way to bring that dso back to live?

[MotoMaxis]

Sure its not a problem. Does it boot into DFU mode? (Turn on with Holding button 1)

If its HW 2.8x then here is everything you need. Load 2 to 5.
RECOVERY281282.zip

For older HW 2.72 and below you must use this FPGA.
hwV272-V261FPGA.zip

[gabonator]

I am trying to put together all information regarding unbricking here, if you have any suggestions what to add, please let me know or post it directly there: #47

[DjangoReinhard]

Yes, DFU mode stil works. So I could copy the rest of the files - but did not change anything.
My hardware is ds203 HW2.70 - so I need the old stuff.

Do I copy both files with dfuload?

[erik-smit]

Thank you. I've been fiddling with my v2.7 DS203 for a few days now since corrupting it with DS203_N1.hex.
Loading these files through dfuload on Linux were successful in restoring my logo and making my DS203 work again.

[DjangoReinhard]

That's interesting! Does your ds203 provide usb-support as before?
Mine does not provide usb-support any more and any filesystem related functions don't work neither.

[erik-smit]

That's interesting! Does your ds203 provide usb-support as before?
Mine does not provide usb-support any more and any filesystem related functions don't work neither.

In which mode are you not getting usb-support?
When in DFU mode or when running the new system_ds203.hex and it's complaining about missing shell.elf?

When running the new system_ds203.hex I saw the /dev/sdb, but didn't see the filesystem.
So I remade the filesystem with sudo mkfs.fat /dev/sdb and then I was able to copy the ds203apps.

[DjangoReinhard]

DFU-mode is working as expected.

With the new system, dso showed welcome screen and then turned into white screen completely - no error message, nothing. No reaction to any of the buttons ...
So I loaded the recovery system which now shows sys ver 1.64 - app (Plus A1) ver 1.13
it complains about missing parameter file and now in dso mode no usb-filesystem.
Linux does not get triggered on plugging dso any more.
But I'm a noob and I have no idea, what to do ...

[erik-smit]

DFU-mode is working as expected.

With the new system, dso showed welcome screen and then turned into white screen completely - no error message, nothing. No reaction to any of the buttons ...

No clue about this.

So I loaded the recovery system which now shows sys ver 1.64 - app (Plus A1) ver 1.13
it complains about missing parameter file

This is accurate.

and now in dso mode no usb-filesystem.
Linux does not get triggered on plugging dso any more.

That's probably because the filesystem is corrupted.

Does it appear in /dev/disk/by-id?
For me it becomes /dev/disk/by-id/usb-Mini_DSO_Flash_Disk-0:0

I don't really feel like customer supporting you through the entire process, but if it appears in /dev/disk/by-id but LInux doesn't get triggered, it means you'll have to rewrite the filesystem with make.fat

[DjangoReinhard]

Thank you very much for your support!
Looks like I can't express what I mean/want.
Loading recent archive brought me original (?) stuff with newer release number but less functionality/more troubles than before.
I had trouble with data storage - therefore I wanted to try your stuff. Now I don't have any data storage and usb is not working any more.
At ds203 repo you said, that it is discontinued and la104 is the new/current project.
Therefore I wanted to try la104.
Don't know, is my hardware too old for your stuff or did I use the wrong words?
Is there another way to get in contact with you, like email or so?

[gabonator]

Yes, the LA104 archive provides support for DS203 as well, but what you get is a simplified version of the oscilloscope compared to DS203 archive and web usb oscilloscope application which I use in most cases. But the problem is that this project works only for DS203 with 2MB eeprom and it is still not optimized to run on 8MB version. And from your description it seems that you have the 8MB DS203 (but I am not 100% sure this was the cause of your issues). So in this case I recommend using the old firmware from DS203 repository

[DjangoReinhard]

I think, it would be helpful to add some comment about /dev/disk2 - that this is not the real path of the device, but may be any like /dev/sdx - whatever matches the connected minidso.
It took me a while searching for /dev/disk2 and find out, why I haven't got one ...
lsusb and following device links leaded to understanding and selection of right device name.

Don't know - knowing that dfuload puts the files at the right place gives good feeling and it was quite easy to copy the files from latest recovery archive and got the dso running again.

The point is, I didn't look for the ultimate dso software, as I only use the dso for quite simple uses. What I missed a lot is a reliable way to store screenshots and copy them to pc.
That did not work on my system. Files got clobbered and rubbish was stored ...
... but attaching dso as usb-storage worked out of the box.

Now usb-storage does not work any more. Neither does saving parameters or screenshots work.
So I'm stil looking for a better software. Simple oscilloscope might be ok. Don't know.
Web-Oscilloscope would be amazing ...
I don't know the size of memory. On board is printed "DS203V2.7B" - whatever that means.

[erik-smit]

Success story/notes on Linux. To test the transfer methods, I'm swapping logos.
ADR/BIN: https://jpa.kapsi.fi/dsoquad/data/jpa/Original%20Firmware/DS203.V2.72.zip
HEX: https://github.com/gabonator/LA104/files/6096611/DS203HW260-272.zip

tldr: dfuload fails for ADR/BIN files. mcopy from mtools on linux works for ADR/BIN files if you sleep 5 seconds between every action. And you can use mdir to check for feedback from the DFU which is nice.

mtools is supplied in the core repositories in pretty much all distributions, so it's probably worth putting in the table upstairs.

• Finding the correct device on Linux. Either check your kernel messages, or check /dev/disk/by-id for usb-* devices:

$ ls -ld /dev/disk/by-id/usb*
lrwxrwxrwx 1 root root 9 19 mrt 17:23 /dev/disk/by-id/usb-Vertual_DFU_Disk-0:0 -> ../../sdb

• dfuload fails for ADR/BIN files. Checking with mdir shows:

sudo mdir -i /dev/sdb
 Volume in drive : is DFU V3_11_C
Directory for ::/

a        ERR         0 1996-12-16   0:00 
A        err         0 2028-12-16   0:00 

I suspect dfuload doesn't transfer the filename, so it doesn't trigger the codepath for ADR/BIN files.

• Copying both ADR and BIN at the same time with mcopy results in .ERR file.

$ sudo mcopy -i /dev/sdb DS203.LOGO.ADR MINIDSO.BIN ::; sleep 5; sudo mdir -i /dev/sdb
 Volume in drive : is DFU V3_11_C
Directory for ::/

DS203L~1 ERR        12 2021-03-19  17:22 
MINIDSO  NOT      8310 2021-03-19  17:22 

• sleeping 5 seconds between actions works

$ sudo mcopy -i /dev/sdb DS203.LOGO.ADR ::; sleep 5; sudo mcopy -i /dev/sdb MINIDSO.BIN ::; sleep 5; sudo mdir -i /dev/sdb
 Volume in drive : is DFU V3_11_C
Directory for ::/

MINIDSO  RDY      8310 2021-03-19  17:23 
DS203L~1 USE        12 2021-03-19  17:22 

• My filesystem was corrupted, so I rewrote a new one with mkfs.fat /dev/sdb. This seems to work for LA104, but trying to save images with https://github.com/gabonator/ds203 results in a very corrupted filesystem, so the FAT settings are probably wrong.
  I've just retried with mkfs.msdos -s 1 -n DSO203 -f 2 -v -F 12 -S 4096 -r 512 -I /dev/sdb from INFO: how to format on ubuntu or other non-bsd distros #26 and this made a 'Assertion failed' warning go away. And now I can see the IMAGE000.BMP when mounting /dev/sdb. However, mdir of mtools sees no files!

$ ls -l /run/media/smite/E8D7-6069
total 192
-rw-r--r-- 1 smite smite    512  1 jan  1980 CONFIG.DAT
-rw-r--r-- 1 smite smite 192054  1 jan  1980 IMAGE000.BMP
$ sudo mdir -i /dev/sdb 
 Volume in drive : has no label
 Volume Serial Number is E8D7-6069
Directory for ::/

No files
$

Oh, well!

[DjangoReinhard]

Thank you very much for your detailled feedback!
It helped a lot.

Making filesystem with sudo mkfs.fat /dev/sdf results in attribute "partition not found
DSO stil vomits error message on file creation.
Linux now gets triggered by plugging dso as usb-device.
Linux sees files created, but each has size of 0 bytes.

New try with mkfs.msdos -s 1 -n DSO203 -f 2 -v -F 12 -S 4096 -r 512 -I /dev/sdf
Result:

mkfs.fat 4.1 (2017-01-24)
attribute "partition" not found
/dev/sdf has 1 head and 4 sectors per track,
hidden sectors 0x0000;
logical sector size is 4096,
using 0xf8 media descriptor, with 512 sectors;
drive number 0x80;
filesystem has 2 12-bit FATs and 1 sector per cluster.
FAT size is 1 sector, and provides 505 clusters.
There is 1 reserved sector.
Root directory contains 512 slots and uses 4 sectors.
Volume ID is c10d4b7e, volume label DSO203 .

Now dso is able to write files. But BMP-files are corrupted, don't know whether others may be correct.

ls /media/tmp/C10D-4B7E/

total 56
-rw-r--r-- 1 dso dso   512 Jan  1  1980 A82FB76A.PAR
-rw-r--r-- 1 dso dso  2048 Jan  1  1980 FILE001.DAT
-rw-r--r-- 1 dso dso 48128 Jan  1  1980 IMAG001.BMP

[gabonator]

Just a side note - to efficiently copy whole filesystem over USB, there are two scripts:

• https://github.com/gabonator/LA104/blob/master/system/scripts/imagefile_make_la104.sh - this will create 8MB filesystem image for LA104
• https://github.com/gabonator/LA104/blob/master/system/scripts/imagefile_copy_la104.sh - this copies created fs image to LA104 (works just for osx, but it can be easily adapted to linux)

Copying whole filesystem at once instead of copying a bunch of files individually has many benefits: It is much faster and it does not rewrite the fat tables every time a new file was copied - saving the eeprom write cycles

The filesystem can get easily corrupted. This is caused mostly by the USB connection. Computer treats the LA104/DS2xx as usb flash disk and does not expect the filesystem to change over time when the device is connected over usb cable. During first start of the gui shell application for LA104 creates lots of temporary files (precached icons) and If you copy new files from PC to the LA104 after some files were created internally, computer just overwrites the FAT records where these new files were added.

So be careful when you are copying new files over USB connection if you are using any application which is writing new files (e.g. temperature logger)

[Peeeet]

If anyone is still looking for answers on this (LA104), I could not get it to load the firmware from any recent up-to-date Windows 10 computer, but I happen to have an old Windows 7 computer and that worked fine.

Also I don't think there are LA104 recovery files anymore in the "Recovery" directory here on this github. It only has DSO203 and DSO213 files listed despite saying LA104 on the directory :-( If we're supposed to use the DSO213 files or something, might want to make that clearer...

[thinkyhead]

NOTE: On macOS I needed one extra step before dfuload would work:

sudo umount /dev/disk4
sudo ./dfuload /dev/disk4 cp system_ds203.hex

… otherwise it would fail with the message …

Failed to open disk '/dev/disk4', errno:60

---

… but, alas, the result was no update, just a faux file named A.ERR.

The direct copy method does get the RDY file, but the app files are failing…

SYSTEM~1.RDY
SHELL.ERR

Device Firmware Upgrade 3.46C

[Aquaerics]

I tried to update the Firmware from the LA104 under windows 7. I can copy the original hex with firmware V1.03 without issues. But the system_la104.hex file from the last release do not work.
Normaly the copy transfer takes some time, than the dfu drives hangs and no files are visible. Some times it goes fast, than the drives reconnect and the "system_la104.err" file is there.
I tried to copy by command line. and i tried to change the drive cache under hardware manager. Wehen the cache is active i can copy the file most of the time and get a reconnect with err file.
I will next try some other windows PCs.

[gabonator]

try copying the same file twice - just drag drop through file explorer. Copy for the first time, wait until the drive reconnects and copy again

[Aquaerics]

If i try to copy a second time it takes some time with a copy window and than the drive is showing as empty. I cann't write to it any more.

[Aquaerics]

Okay, i figgered it out. I used the right mouse button on the drive. and in german you could slected "als tragbares Gerät öffnen". Than i could coppy, reconnect and get the ready signal. Perhaps that helps someone else.

[ZoserLock]

On windows 10 I was able to flash the Nov 12, 2020 version of the LA104. (after changing the .err extension to .hex). The lastest version, on the other hand, don't copy into de device and windows says that the device malfunctioned and close.

[SpudGunMan]

can you boot up a virtual box or something for linux or use a DFU tool you might have AV/Defender making a mess for you in windows

[troyhacks]

LA104 on Windows 11, Copy Hex Twice = Worked

Second copy appeared to error, but flashed fine.

[roger1950]

Hello, can someone tell me where I get the system.hex file from since I can't find it anywhere, thank you

[Basitadam]

https://github.com/gabonator/LA104/releases/tag/2022.12.12