Possible Bug/Overlooked-Problem burning an 89V51RD2.

[Jacob]

Hi There!

Im an EE college student, and have been successfully using the 89V51RD2 along with FM for the last two years.
My project this year uses the 89v51's UART, so ive started experimenting with it to figure it out.

Basically, I wrote a program that transmits the same byte in infinte loop. I Checked it with a scope, worked as expected and everything, and then when I wanted to write a new program to the chip I got the classic "Unable to connect at the specified baud rate. Try reducing the baud rate. Reset the hardware into ISP mode again."
My circuit seemed to be working fine so eventually I turned to manual resets. It took a few tries (given the small 400ms delay) but at some point I managed to get FM to write a different program to the chip.

I was still curious though, so I played around with this a bit...
On a few occasions I even got the un-common "Failed to read the device signature (Operation Failed. (reading sigature)). Accessing a device using the wrong protocol could render the device unusable. Do you want to continue?"

Anyway, i wrote the following program:
                 MOV TMOD,#00100000B
    MOV TL1,#-15
    MOV TH1,#-15
    SETB TR1
    MOV SCON,#01000000B
    MOV DPTR,#0F000H ; this external address is connected to a switch
    MOV R7,#0A0H
LOOP:    MOV SBUF,R7
    JNB TI,$
    CLR TI
CHK:    MOVX A,@DPTR
    CJNE A,#1,LOOP
    SJMP CHK   

Anyhow, various tests all pointed at the same suspect, the UART.
I dont think its my reset circuit, since the chips pin no.9 definitely got a positive signal for a decent amount of time.

My teacher couldnt explain it so he recommended that I come here, and here I am.

I was wondering, is this is a common problem, or was I doing something wrong? Not utilizing some feature of FM?

               thanks in advance,
                                      Jacob

[Andy Ayre]

If you erase the device and then cycle the power do the problems go away?
Can you attach a hex file to your post?

Andy

[Jacob]

Thanks for the Reply.
I tried your suggestion but the problem remains.

I changed the program so that Timer1 auto-reloads with 200, meaning a baud rate of about 560.
When I try burning with a baud rate of 2400, I get all the problems  I mentioned earlier.
When I raise it to 9600 it works better but i still get "failed to read the device sig" error once in a while.
Raising it to 19200 makes it work even better and seems to lower the chance of me getting the "failed to read" message, though I still get that once in a while.

It definetly seems like theres a connection between the baudrate the Chip was operating to and the one FM trys to connect at.

Anyway its either a problem with my programming, my base circuit, FM, or, the Nxp Production line 
Next time I get to the lab ill try another Chip, that might be the problem.

In the meantime, attached are the Hex file and the Basic programming circuit we're using.

Thanks again
Jacob

[Andy Ayre]

Using baud rates below 4800 is quite unusual, and may be the reason for your problem. I'm not sure what the exact cause is though, but I would suggest you stick with 9600 or 19200.

Note that when you place the device into programming mode the bootloader measures the bit times of an autobaud character ('U') then tries to work out the baudrate being used by the PC from that. Therefore the bootloader should be performing all necessary initialization of the UART and what you have programmed into the device shouldn't have an effect. I think you demonstrated that by erasing the device and still having the problem.

The method to place 89V51Rx2 devices into programming mode can sometimes be problematic. I would suggest you look at the newer 89CV51Rx2 devices that use the logic level on a pin.

Andy