Messages

PS2: More experiments
Experimenting I found out that the problem is associated with chip being set to 12-clock mode. In this mode, the Timer2 clock is fosc/2 rather than fosc; hence it is impossible to set the proper reload value for 57600bps @ 12MHz (which would be 6.5). Setting the chip to 6-clock mode, it is possible to operate the UART at 57600bps @ 12MHz; but due to inherent uncertainty in determining the baudrate with the autobaud routine it sometimes works and sometimes not (experiments gave me a 1:1 ratio).

Nevertheless, the chip is set at 12-clock from the factory, so it is impossible to change the double-clock bit via ISP at 57600bps @ 12MHz.

The Philips datasheet is far from being crystal clear as the Timer2 operation as baudrate generator - the picture contains a ":2 box" between oscillator pin and timer counter; while the following text states several times, that the input frequency is fosc - and it is mentioned nowhere that this is clock-doubling dependent.

Although the operation of chip and unclear datasheet is not Andrew's problem, the resulting unclarity as per bootloader operation is (at least he needs answer questions like these).

Jan Waclawek

There is not a single reason why the bootloader would not use the best available method for baudrate generation - Timer2.

As the autobaud routine measures only a single negative pulse to determine the baudrate, with assymetric shift in up and down going edges (which is not rare at RS232, especially at longer cables and higher data rates) it can easily end up with an improper reload value for Timer2. Indeed, if in the given case the reload value differs by 1 from 13, the error increases to 7-8.5%, which is just good to produce intermittently working connection - exactly as described by the original poster.

As Andrew pointed out, a small deviation in the determined reload value has much less detrimental effect at lower bitrates.

Anyhow, any serial communication is usually more reliable at lower speeds, regardless of the exact cause.

Jan Waclawek

PS. Apart from theory, I just tried the given setup (57600bps, 12MHz) and the bootloader obviously invariably sets the reload value to 14, which gives 53571bps, 7% error. Pretty unusable; sending "U" (55h) echoes randomly 75h and 35h...  
38400bps works quite fine...



Post Edited (02-23-05 03:34)

This should not be the case, as using Timer2 for baudrate generator gives a rather negligible error of 0.16% with 57600bps at 12MHz.

Of course, you can still use 9600bps (with the same error).

I would suspect an incorrect level translator (MAX232 or similar) or wiring problem.

Jan Waclawek

http://www.efton.sk/t0t1/unsoftice.htm

Have fun!

Jan Waclawek

Ooooops, sorry, corrected that.

Jan Waclawek

1. For the P89V51RD2 programming, you need to use only the Rx and Tx pins (except power supply). Leave  /PSEN  unconnected, and /EA tied to the + supply voltage.
2. Don't use a simple pushbutton (switch) connected between RESET and +Vcc as a reset button. Use a proper reset circuit (e.g. a cheap 7705), they usually have pushbutton inputs. Or use a 3-terminal reset circuit and perform the reset by switching off and on the power source.
The reason is, switches tend to bounce (making short pulses) and most of the '51s tend to do unpredictable things when supplying a shorter than the needed 12- or 24-clock reset.

Jan Waclawek



Post Edited (01-25-05 06:14)

If your device has connected the Rx pin and receives a stream on it (it may be unintended- e.g. when using it as a general purpose input) and if it sees an 'U' within this stream, it may (spuriously) enter the ISP mode.

Jan Waclawek

The chip may be in the SoftICE mode. You can check it this way: get a terminal program capable of sending binary/hex characters (e.g. term by bray). Power on your board and send 11h ($11) mulltiple times. If the chip responds alternating $00 and $FF, then it is in SoftICE mode.

Jan Waclawek

Maybe a simpler method can be employed.
Rather than writing a complete downloader on your own, try implementing only the "Reset now!" "button" while sending out "U"s, until the device responds with "U" (indicating successful autobaud and entering ISP mode). At this moment, you can spawn to FM (keeping the same baudrate of course) with parameters as already suggested.

This is only an idea, not tried.

Jan Waclawek

PS. When sending out the "U"s (=55h), either make spaces between them or send alternating  55h and 0FFh .

> Could
> you point me to a source for the detailed specification of the
> download protocol?  

The P89V51RD2 datasheet, at the Philips site.
Particularly chapters 7.1.2 and 7.2.4.

Jan Waclawek



Post Edited (01-11-05 02:05)