when i applied the new v300 hijack kernal with the kernal flash utility, i got the meesage below in the DOS window. never got anything like it....any ideas?

found empeg unit: entering program mode
manufacturer=0089, product=88c1
waiting for prompt
starting erase [100%] erase ok
starting program at 0x10000 [Failed to get echo-back on lock/unlock command.

Error: lockpage(10000,1) got code 1

Can't say I've seen it, but incidentally, did you try flashing a second time, to see if it was transient?

Try:

- Pull the empeg's power. Do not plug it back in.

- Start the kernel flash process.

- When prompted, and only when prompted, apply power to the empeg.

If that doesn't work with the hijack kernel, try the same thing with a standard .upgrade file.

If that doesn't work, try a different cable AND a different computer.

I get the same error message. Tried 3 times. I flashed v299 back on for now.

So 299 worked but 300 didn't? I didn't realize that. That's strange. Wonder if it's something about the file.

Okay, I get this exact same error message when I try it. So it's not your cable or your PC or a corrupted file download. There's something unusual about the file, its file name, or something. I am investigating.

This is exceptionally odd.

- Jemplode has no trouble upgrading the player with v300 via FTP.

- The file that Jemplode auto-downloaded and successfully upgraded the player with is binary-identical to the one that I downloaded and tried to upgrade with using Logoedit. So there's nothing wrong with the file.

- It's not file size, because I've used logoedit before to upgrade the player using both smaller files as well as larger files. At least I think I have.

- I know my upgrader and cable are working because I can easily apply the V299 upgrade with logoedit.

Still investigating.

Nope, not file size, because:

- Easily upgraded to v299 from serial, file size 455k
- Easily upgraded to v271 from serial, file size 505k
- v300 is between those two sizes, at 480k.

Not a problem with the file NAME because it's nearly identical in name to the others that successfully upgraded, except for the 300. And I even tried renaming it to "new.zimage" and upgrading from that. No dice.

Not a problem with the file itself because Jemplode has no trouble upgrading the player successfully with v300 (albeit through FTP not serial).

Is it possible that it's something in the binary data of the file itself... something where a certain sequence of binary characters will screw up the flash pump firmware or the download.c code?

I know that sounds unlikely, but the old Sherlock Holmes mantra is running through my head now: When you have eliminated all other possibilities, whatever remains, however unlikely, must be the truth.

What other possibilities must we eliminate?

I guess it's time to start using Jemplode.

Thanks Tony for looking into this.

Used Jemplode, v300 loaded no problem.

note: well, even though i got the error, it appears that there is no problem using the player and hijack features for me.

The Empeg-supplied "download.c" also works perfectly (under Linux) with v300, so there's nothing wrong with serial kernel flashing. The error message people see is coming from (1) Windows or (2) logoedit, so those are the two places to look.

Cheers

The error message is from the Upload.exe program that is used with LogoEdit.

-ml

I haven't tried, but does it work with download.c?

Jemplode probably just uses ftp to upload the image to /proc/empeg_kernel, so it is not even going through the empeg's builtin flash programmer.

I looked at the download.c source and it looks like the programming actually should be ok, the player must have even ok'd the last 28 byte block.

Is the logoedit code identical to download.c compiled for windows?

It fails to relock the first page it tries to lock, but that the data sent for that operation is identical whether you're flashing v300 or v299. Maybe the timeout is too short and it normaly doesn't trigger? Or did that last 28 byte block write fail after all. Perhaps it is a combination of the two. As the last write is only for 28 bytes, perhaps the flash programmer is 'initializing' the rest of the relatively large flash page and that delays it long enough to miss the timeout, or it starts writing stuff too late so that flushrx didn't get a chance to actually get rid of the '?' (prompt that is sent by the bootloader).

Add a sleep(1); to the beginning of lockpage, or try to pad the image to a larger size, so that the last bytes aren't as close to the flash-page boundary anymore.

I looked over the source code for download.c (which is what LogoEdit uses a modified copy of), and the error is happening right at the very end, as the program tries to write-protect the kernel after is has been downloaded.

So.. it's all there at this point, just not completely write-protected..

-ml

Okay, so that eliminates the player flash-receipt code.

It's gotta be something windows-specific that the UPLOAD.EXE code doesn't like.

Attached is the Logoedit version of download.c. Anyone see anything that might cause the problem?

>I haven't tried, but does it work with download.c?

Yes, download.c works just fine under Linux at least.

And I double-checked to ensure that the unit I tried it on
has the same kind of flash that gives the error with LogoEdit.

-ml

Try this patch to upload.c and let us know what happens:

--- upload.c.orig       Thu Oct 17 12:32:25 2002

+++ upload.c    Thu Oct 17 12:38:35 2002

@@ -743,6 +743,7 @@

     printf("%3d%%\010\010\010\010",(done*100)/length);

     fflush(stdout);

   }

+  fsync(i);

   fclose(i);



   /* C3 flash? */

Why bother to fsync the file that is being read??

So I'm just adding the one "fsync" line, that's all? What does that do?

The only thing I can think of is that flushrx hasn't flushed all incoming characters. Maybe your machine is too fast This change should make it wait for up to a second for possible incoming data instead of simply returning right away.

static void flushrx()
{
- while(readbyte(0)>=0);
+ while(readbyte(1)>=0);
}

Well, I can't reproduce the error on my work PC even with the original code, so I won't be able to try this out until I get home and I'm doing it in an environment where I can reproduce the bug.

In the meantime, I'll solicit suggestions for LogoEdit improvements in another thread. The software hasn't been updated in almost two years, and I might as well take this opportunity to improve it.

Good point.. I got briefly confused.

Okay, my theory is that the final write operation is still in progress when the program begins trying to lock the pages again. Dunno why, but nothing else explains it nicely.

So, put a sleep(1) there instead of the fsync().

And modify the lockpage error message to actually dump out what it read back, instead of just blindly complaining.

Cheers

So, put a sleep(1) there instead of the fsync().

Interesting. That seems to have done it. Will do more testing to be sure, but that seems to have taken care of it.

THANK YOU!

(Had to use the Win32 version of that command, though. Capital S, and the value is in milliseconds so it was Sleep(100); but the point is that it worked.)

For anyone who doesn't want to wait until the full release of the next version of Logoedit, I have attached the fixed version of upload.exe here. Simply copy it over the original upload.exe in the logoedit installation folder, and you're all set.

While I'm at it, there were a couple of other threads a long time ago that complained of a similar error, but in the erase stage rather than the lock stage. Do you think it could be the same thing?

http://empeg.comms.net/php/showflat.php?Cat=&Board=bigs&Number=43878
http://empeg.comms.net/php/showflat.php?Cat=&Board=empeg_tech&Number=30144

If so, where would I put the Sleep command?

Here is an even newer one which also sleeps before checking for the echo back on the erase command.

Sigh, people just don't listen to me. If you had made that change to flushrx like I suggested you would automatically get the 'waiting for the prompt' sleep at every point a command is started.

If you want people to listen to you, patch a wav of yourself into gpsapp?

Well, that or patch in "flite", but that's not the same...

There's a slight difference though, it really just needs one single sleep after the final write, not after EACH write.. much quicker this way.

But of course you suggested it first!

Cheers