Find free programmer for Ds87c550 & Ds89c450

monnoliv said:

What is the speed you reach without error ? (be honnest, because I saw some posts here that are not famous).

YES with 32MHz I got 115200 bps. I know that because I got 64k flash in 15 sec.
With 7.3728 MHz I didn't succeed to cross beyond 38400 bps due to the reasons mentioned above.
If I set the reload value of timer 1 according with 115200 and receive the "G" ACK means that 89C450 communicates with PC at that specific baud rate.

Click to expand...

Click to expand...

monnoliv said:

I hope that both of you agree using the crystal multiplier feature of DS89C450.
This way we can achieve EMI reduction, too.

Click to expand...

Yes but ...

But this approach (using crystal multiplier) leads to lower speed flash programming.

Click to expand...

That's the problem and the reason why I choose near 33MHz clock generator.

Obvious if the length byte inside record type 00 is less than 16 then the command "L" must be issued more than 4096 times.
This could happens if the assembler or C compiler don't build the hex file in constant 16 bytes chunck / record.

Click to expand...

Yes

Now comes the advice: New records SHOULD not be transmitted until the ACK/NACK byte associated with the previous record has been received.
The best ACK for us is "G" that means record was received and programmed without error.
How fast the "B" comes after those 20 bytes has been sent ?

Click to expand...

Don't bother, just check in the meantime then the ack is good.

Someone could claim that depends of the time required for flash cell programming. How much is takes ?
If we look into data sheet page 11, tPROG = max. 40 uS.
If we look into IAP section at page 23 the FBUSY bit may not change state for up to 1 uS.
Since I'm expected that ROM Loader uses the same registers FCNTL5h FDATA6h like IAP does, I believe that 1 uS is that prog time.
Now, how much time it takes to program 16 bytes ? Yes, you guess 16 uS, regardless the overhead time required by routine programming which ends waiting for FBUSY to return to 1.
Included in this routine are preprogramming assessment and postprogramming verification, too.
How much time it takes to send serially the payload 16 bytes at 115k baud rate ?
20 bytes x 11 bits (Start bit + 8 + Parity + Stop bit) x 1/115200 = 2 mS which is by far greater than time required to program them in flash.
Thus we can't say here it's the bottle neck which limits the speed programming.

Click to expand...

Do you have the source code of the bootloader ? I don't have it. Doing some estimation is good but I've done some experimentation:

Here are the result of my tests (I spent several hours for this, including generating dummys 64Kb .hex files for the bootloader). The result is the fastest download without error (all ACK are G)

64Kb Hex files, 8 effectives bytes per row, 8193 rows => 12
64Kb Hex files, 16 effectives bytes per row, 4097 rows => 13
64Kb Hex files, 32 effectives bytes per row, 2049 rows => 14

Then the fastest upload reached is 14*8192*11/12 = 105130 bauds

Note that the more row we have, the more bytes we have to upload since each row contains bytes that are not effectives.

These tests are enough accurate for me, I can't spend more time on this.

Click to expand...