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..

EDIT: Ah. The download.c program is actually sending commands to a firmware blob on the empeg, which is then talking to the flash memory. So if there's a bug, it appears to be in that firmware blob. Ugh.


Or maybe something has gone wrong with the WP input to the flash chip? I think that's only to protect the mysterious firmware blob itself, not the rest of the flash.

Dang, so I have two bricked players? Should I try to get a scope on that WP line... though I don't think I could get it captured correctly as I don't have a digital scope.

Thank you sir! Sadly, I get looped:

(base) time@time-OptiPlex-790:~/Documents/mlord/0x2a bypass$ ./download ../../../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, continuing regardless..
Bad result code: 0xa2, continuing regardless..
Bad result code: 0xa2, continuing regardless..
Bad result code: 0xa2, continuing regardless..
Bad result code: 0xa2, continuing regardless..

Endlessly.

I super appreciate all your help on this! Given the people on this board if anyone can figure it out, it will be this crew. Thank you so much!

So this schematic got me looking... This doesn't seem right: [img:center]https://photos.app.goo.gl/tf78cj6XewCQWWU17[/img] and specifically, [img:center]https://photos.app.goo.gl/D3yvHt1ULpf9Wao88[/img]

It looks like solder paste or some kind of cap leakage seeped under, but there are no obvious sources anywhere near it.

I've flushed with 97% Isopropyl and then some DeoxIT D5 using a 0.3mm syringe and a wee bit of scraping. A flush and then blew it out with air. Looks better, but waiting for it to dry before try again.

<some hours later...>
Same result. Gets to 24% and errors. I don't know what that is under that first row of pins--it is not on any other device on the boards and nothing was ever spilled in there. I've been very careful to treat these with great care even when not in use. Maybe it is not related.

That's v1.00, an earlier version of the firmware blob. Is this a Mk2 "empeg", or a Mk2a "RioCar" ?

I see the IC9 Rev 1.00 sticker there, but one is a Mark 2 empeg player. It is also happening on a Mark 2a player as well. Same pattern of behavior.

My original player (SN 080000404) QA Inspected 15/8/00 is a Mark 2 empeg player with a mainboard version stamped Issue 7 Rev. 1 (c) 2000 with that "IC9 Rev 1.00" sticker.

The second player (SN 010101705) QA Inspected 21/3/01 is a Mark2a RD100-20 RioCar player with a mainboard version identified as Issue 9 Rev. 2 (2000) with the IC9 chip sporting a sticker of "1.02".

Both were previously on a version of Hijack from 2002-2003 era.

Waaaaait, you can't just use a whole ".upgrade" file with download.c... download.c is a fairly raw "rewrite this area of flash" tool, but an upgrade file contains several different chunks of data, some of which are meant to be written into blocks of the flash, some of which are meant to be written to disk. An upgrade file is bigger than the whole of the flash chip.

The command you want is called "upgclient", though I'm not sure where to find it these days.

Peter

The "block is locked" errors you were getting, probably mean that the flash writing wrapped at the flash size, and only the write-protection was saving you from overwriting the essential early blocks of the flash, something which would have bricked the player. Well done "us" (actually it was probably before my time) for adding that failsafe...

Peter

You can split the upgrade file into chunks and use 'download' on each chunk. Here's me doing it about 6 years ago: https://blog.differentpla.net/blog/2019/03/29/empeg-msata/#extract-the-upgrade-file-parts

Caution: this was with the empeg's disk attached to my Linux PC, but with the empeg attached over serial. You want just the 'upgrader' and 'download' steps.

I'm glad somebody's memory is working here! Thanks Peter!

Yes, download.c is normally just for the Linux/Hijack kernel itself, not for the other masses of data blocks that actually get written to the primary hard disk.

<smacks head>
That make some sense. I'll need to parse this out and see where I get. Thanks Peter/Roger/mlord! As ever, you guys are so awesome. Your glorious platform has had me itchy once again for the joy that is the empeg--even after 25 years.

I'm particularly excited to mess with the web empeg interface. Getting these type of updates is so stunning after so much time.

Once I get some free time later today I'll give these steps a whirl. Hope all is well.

Thanks again!
Tim