Well... I got:
Found empeg unit: entering program mode
Manufacturer=0089, product=88c1
starting erase [Bad result code: 0xa2

That doesn't sound good.

That just sounds like it had a comms error. Still on MS-Win, eh?

Ok. No, this was download.c on Linux Mint.

I'll see about ordering a new null cable.

The cable appears to be working. It could just be perhaps needing a different chipset in the USB-Serial Adapter.

What does 'lsusb' show for the adapter?
If I have a similar one here, I could re-test against it.

Cheers

Nope. That's not it. New null-modem cable does the same thing. It gets about 16-20% through the erase and throws that error. Any other ideas?

This is via a 9-pin to the 9-pin on the empeg.

Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0040:073d
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Is that what is reported for ttyS0?

dmesg shows:
[ 0.563684] 00:03: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A

Changed to stty -F /dev/ttyS0 cs8 -parenb -cstopb and tried again.
Still [Bad result code: 0xa2

Tim, is it in a docking sled? If I recall correctly (Mark, correct me if I'm wrong here), the player serial port is 4800bps in the docking sled, and it won't do flash upgrades when docked.

https://riocar.org/FAQ/8/74.html#74
https://riocar.org/FAQ/7/82.html#82

Oh, okay. Not a USB-Serial cable/dongle then? A real, built-in serial port with DB-9 on the computer itself! (?)

Mmmm..

Here (attached) is the download binary I use, which works for me on Linux.

Hey Tony! No sled. Just on the desk.

Sorry sir, I only act like I know what I'm doing on linux. I tried chmod 755 download.bin and trying to launch it says:
download.bin: command not found

./download.bin

Are you trying this on a simulated Linux (eg. "Linux for Windows") or some such trash, or on a native install?

That still gets me. Frequently! I'm no expert on Linux, and my main driver is a Mac these days, and I hardly ever need to do anything at a DOS command prompt any more. Yet still, that's one of those things where, even if you know it, it still seems like it should work without the ./ in the front. Frustrating.

Someday I'll look up WHY it works that way. Still probably won't help me remember.

(Edit: Just did look it up. Supposedly it's a security feature to prevent a malicious program with the same name as a program in the PATH (like LS or MAN etc) from being automatically called in lieu of the real one from the operating system. Microsoft, on the other hand, chose convenience over security when designing their command line syntax.)

Native Mint 20.2 (Uma) install on bare metal.

Ok. Now prompting for an <address in hex>

./download.bin image_file_name 10000 /dev/ttyS0

But you already attempted to use download earlier, so same syntax as before.

(base) time@time-OptiPlex-790:~/Documents/mlord$ ./download.bin ../../Downloads/car2-developer-v2.01-final.upgrade 10000 /dev/ttyS0
Turn on empeg unit now
Found empeg unit: entering program mode
Manufacturer=0089, product=88c1
Starting erase [Bad result code: 0xa2

Yup. Increments to 24% and then errors.

I've even tried briefly shorting the 3v cell on the mainboard and retrying the reset in hopes of forcing a reset, but get the same results.

DOS didn't have directories until 2.x, so commands were always in the current directory (or built-in), so it didn't have a PATH environment variable. Microsoft chose (as they almost always do) backwards compatibility.

Mmm.. So either bad flash, or a bug in the download.c program. I would try just circumventing the failed test, and see how far it gets after that.

Here's a hacked copy of the source code which does that (attached).

Cheers

Mmm.. Okay, Status 0xa2 is composed of these three bits:

0x80 :: Device is idle.
0x20 :: Erase failed.
0x02 :: Prog/Erase attempted on a locked block, operation aborted.

So, probably not bad flash, but something wrong with the programming method. The download.c source code appears to correctly attempt to unlock blocks before erasing them, so this shouldn't be happening. I'll look a little closer to see if Hugo has a bug in there somewhere..