Unable to ISP P89V51RD2BN

[Ram]

Dear Andy,

We designed the attached schematic for P89C51RD2BN
(we call this board the "HMI board"). It is working
as we intended.

We connect the HMI board via MAX232 to the PC. We
have used various versions of Flashmagic. We are
currently using the latest version: 5.201717.
We are able to ISP the p89c51 by shorting pins 1 and
2 in JP1 (on the left hand side of the schematic).
Indeed, we have ISP-d the p89c51 maybe over a hundred
times and are pretty comfortable and happy with its
ISP feature.

About a year ago, we saw that the p89c51's were not
available in the market anymore. Instead, P89V51RD2BN's
were. So, we bought about 10 of the p89v51's.

We have been trying to ISP the p89v51's ever since.
But, we have not been successful yet. For testing that
our connections are alright, we first ISP the p89c51,
power off, remove the p89c51, do not make any
modifications in the circuit except removing the short
between pins 1 and 2 in JP1, and insert the p89v51 in
place of p89c51.

On the Flashmagic side, we do the following:

1. Uncheck "use DTR to control RST".
2. Set the following under Step 1: 89V51RD2, COM 1, 9600,
   None (ISP)
3. Check the following under Step 2: Erase blocks
   used by Hex File
4. Under Step 3: Select the hex file to be burned, say
   targetboard.hex
5. Under Step 4: check "Verify after programming"
6. Hit Start

Flashmagic says, "Reset the device into ISP mode now".
We either switch on the power to the board, or if it
was already on, then we press the reset button S2 in the
top left hand side of the attached schematic.
Then we hit the cancel button on the Flashmagic pop up.

The message disappears and nothing happens.


We have tried various other things:

1. We have burned the boot code available at
http://www.flashmagictool.com/assets/resources/P89V51Rx2_Bootloader_Update.zip using our universal programmer.

2. We have also burned the boot code available at
http://www.nxp.com/files/products/standard/microcontrollers/utilities/p89v_lv51rd2_bl_upd_v5.zip using our universal programmer.

We took care to burn these codes in Block 1 of the
p89v51.

3. We tried all the baud rates less than or equal to 9600.

4. We used a terminal program (equivalent to Hyperterminal)
and sent out "U" characters to the Rx pin of the p89v51, and
saw if we were receiving anything.

Here we noticed something interesting: nothing was coming
back to the terminal program from the HMI board.

But, when we tried a different (bare bones) board that
contained only the MAX813L, with the pushbutton for manual
reset, a 11.0952 MHz crystal with its capacitors, and the
Rx and Tx pins brought out to our MAX232, then we had U's
coming back to our terminal program in response to U's sent.
When Vdd was 4.96 V on the bare bones board, we had the
returning 55's (hex for U) interspersed with some FF's, while
for Vdd above 5.05 V, we had only 55's. Even when we have
only 55's returning, we are unable to enter the ISP mode.

Of course, we need to further investigate this difference
in behavior between the HMI and the bare bones boards.

Do you notice anything in our HMI board's schematic that
would prevent the p89v51 from entering ISP mode?

There is one another question: On our universal programmer,
when I load the boot code's hex file that I downloaded
from flashmagic's site, I need to select the file format
from several options presented to me under "auto format
detected". Two options seem to be most relevant to this hex
file --- "intel" and "intel hex 16". I have been selecting
the first one assuming that your hex file is an intel hex 8
file. Please let if my choice was correct and if "intel"
means "intel hex 8". The documentation of the universal
programmer does not contain anything on this topic.

Thank you.

With best wishes,

Ram.

[Andy Ayre]

Thanks for the detailed posting. It's an example to others on how to investigate problems and present findings.

Firstly don't click on Cancel in the window that opens telling you to reset the device, unless you are giving up waiting. If Flash Magic gets a response then it will automatically close the window. Perhaps you didn't wait long enough? However the fact that you didn't get an echo when using a terminal program probably indicates that it won't work anyway.

Apart from that your steps look ok to me.

The 89V51RD2 doesn't use /PSEN for ISP entry and I'm not sure what would happen if you closed jumper JP1, so you might want to compare that aspect with your other board.

Looking at your schematic I don't see anything that stands out. But there must be a difference between your two boards. If you haven't already I suggest measuring the voltage at VCC, VSS, RST, /EA and /PSEN on both boards and look for a difference. Also check for glitches and ripple. Check there is a sine wave at XTAL1 and XTAL2 and it's the same on both boards. If the devices are socketed try moving them between the boards and see if the problem follows the devices or stays with the boards. Also use a scope to compare the reset waveforms for both boards.

To update the bootloader you should use the hex file (which is from NXP, not us) with the "Update Bootloader" option on the ISP menu in Flash Magic. This will program the hex file then execute it and make sure it succeeded.

Having said that, and the fact you've been struggling with this for a year, you might want to just get some P89CV51RD2 samples. This is a newer device, newer than the one you are using, and with it NXP returned back to the 89C51RD2 style of ISP entry.

There is only one specification for Intel Hex files that I am aware of. Sometimes compiler or programmer companies will use different names to distinguish from hex files that use a 16-bit address range and those that use a 24-bit or 32-bit address range. For example Keil uses Hex-80 for 16-bit addressing and Hex-386 for 32-bit addressing. This may be what they mean. If one doesn't work try the other, but I would expect the programmer software to generate an error if it didn't like the format of the hex file.

Note that Flash Magic supports everything in the Intel specification.

[Ram]

To update the bootloader you should use the hex file (which is from NXP, not us)
with the "Update Bootloader" option on the ISP menu in Flash Magic. This will
program the hex file then execute it and make sure it succeeded.


Having said that, and the fact you've been struggling with this for a year,
you might want to just get some P89CV51RD2 samples. This is a newer device,
newer than the one you are using, and with it NXP returned back to the
89C51RD2 style of ISP entry.

Dear Andy,

I will write back soon about those things I am not addressing in this post,
those that you asked me to try.


While using the boot code hex file from NXP, we are going by the following
upgrade instructions from NXP:

"The bootloader software programmed into the Philips P89V51RD2 and P89LV51RD2
microcontrollers can be updated either by using a commercial parallel programmer
or in-system by executing a bootloader update utility."

"Using a commercial parallel programmer" The operating instructions for
commercial eprom programmers vary considerably. Thus, in order to erase and
reprogram the booloader code, the user should consult the instructions/manual
provided by the commercial eprom programmer manufacturer. The hex file
"P89V51RD2_BL_V05.HEX" contains the new Version 05 code."

In my first post I mentioned the care that we take in burning the boot code
using our universal programmer.

We took the universal programmer route because we reasoned that as we were
unable to get the ISP to work, we would not be able to update the bootloader
using the "Update Bootloader" option on the ISP menu in Flash Magic, as you
suggest. Do you think that we should still try the update bootloader via
Flash Magic?


About the P89CV51RD2's NXP says that these are drop in replacements for
P89C51RD2's. But, the p89cv51's do not come in 40-pin DIP version. On the
other hand, as our schematic shows, we are using 40-pin p89c51 versions, and
they are DIP. So, the p89cv51's are not really drop-in replacements for
our p89c51's. Also, we need the 64 kB flash, 1 kB RAM, the timers, and
the UART that our p89c51's have. Do you have any suggestions?

Thank you.

With best wishes,

Ram.

[Andy Ayre]

If you have been trying to get this to work for a year then I would have assumed that a hardware change to a different package type to get the problem solved would have been an option. However I don't know all the requirements of your project so I can only throw out ideas to try and help you.

The NXP website gives a complete list of available 8051-based devices. I suggest you look through it to see if there are any other suitable devices. However, I suspect that you would have to make a compromise somewhere.

You mention that with your bare-bones board you can get it to echo back 'U's when the supply voltage is high enough, but then you give the vague statement "we are unable to enter the ISP mode". What does this mean, exactly? As the bare-bones board is the closest to working I would focus on that. Namely getting it to respond to commands in the terminal. If it is reliably echoing 'U's and your application does not do that also, then the bootloader is executing and autobaud has completed.

Andy

[GeeMott]

I haven't had experience with this exact part, but I know that others in this family can be very finicky.  If you do the wrong thing one time, there is no way to recover.  I have had symptoms similar to yours: getting back the U's but not entering ISP mode, etc.  It is possible, just possible, you ruined your batch of 10 early on, and nothing after that will work.

First thing I learned the hard way: always start FM and select the correct part before applying power to the board.

Second, ditto: on a fresh chip, always update the bootloader first thing.

Other than that, your trick with the supply voltage is VERY suspicious.  There really shouldn't be a difference between operating at 4.96 or 5.05.  Are you sure your power is clean and has plenty of current available?

[Ram]

Dear GeeMott,

I have decided to take a break from trying to program this chip via ISP.
I have been using a parallel programmer since I last posted my problem.
I may move to a P89CV51 in a few months from now. In the meanwhile, I
have built a new HMI board with a ZIF socket in it to hold the P89V51
that we already have. Once the programs are finalized, we may build the
HMI board using SMD components. Then the P89CV51 may come of use. I
thank you and Andy for taking an interest in my problem and for trying
to help out.

With best wishes,

Ram.