Messages

[C]

Could you please tell me that from where I could download bootloader for P89C51RD2BN chip?
I want hex file so that I could reprogram the bootloader to the IC.

AFAIK, the default bootloader in P89C51RD2 is in ROM, so you can't reprogram it (nor you can "lose" it).

Why do you want to do that?

JW

Well..... you know..... No. :-)

As per datasheet, the watchdog counter is incremented once each 334064 clocks (AFAIR the datasheet* explicitly states XTAL1, so no confusion can arise whether this is x2 or not). If the watchdog counter (WDTD) is set initially to FB (and it is - you can check it yourself), it  rolls over after 5 increments and that's the point where it resets.
Now the calculation in the datasheet says slightly less - 334064 * (0xFF - WDTD) - but that's IMHO just the "safest minimum"- the 334064 divider apparently may start up at a random value... But, all in all, being it 4 or 5 "cycles", it's still in the 100-150ms range, which is further than 400ms...

If I am allowed a guess, the 400ms came from some sort of error or maybe a different specs than the final one. For example, if you start from a maximum clock of 33MHz (which was the maximum clock of the SST's predecessors of this chip), the 33something divisor starts to make sense, the watchdog timeout is 10ms per one watchdog timer tick (and, indeed, the older SST chips had an independent internal oscillator for the watchdog, ticking approx. once in 10 ms!). So, with the reload value of 0xFB and 33MHz, you get around 40ms, which with a small typo of making one extra zero yields you the datasheet value... OK this is pure speculation... Ask perhaps the insiders at NXP...


Jan Waclawek



---
* It certainly does, but I don't remember which one - the NXP/Philips, or the "original" SST - you certainly already know this line of me... :-)

Now the question is: why the 89V51RC2 starts the user firmware so quickly?
NXP stated that it should delay 400ms @ 12MHz (see NXP app.note TN06007.pdf), and my own board clock is just 12MHz.

Well, I have no idea where they got the 400ms from, and I am afraid neither does NXP...
The bootloader timeout is given simply by loading #0fbh into WDTD, and starting the watchdog. Please calculate the timeout yourself...

JW

PS: Andy: shouldn't there be a faq for this?

We have a list of standard debugging steps: http://www.flashmagictool.com/debugstart.html which is also a sticky topic.

Andy

Oh I see... Sorry...

I now see I have already added the quick'n'dirty COM go-nogo test there...

I'd add the general '51 "does it run at all?" tests... Or shall I add them into the 8052.com's FAQ and point to it from here?

Also, Joe's 'V51-specific remark should be added there somewhere... Is it a good idea to edit that old post of me, or shall I ad an another one?

Jan Waclawek

Do the tests in this order. If one fails, no reason to go for the next, but fix that first.

1. verify that your serial chain is OK: start a terminal on PC, pull out the 'V51 (I hope it's socketed), short the Rx and Tx in the socket and type in the terminal - you should see what you type (having local echo OFF, i.e. if you disconnect the short, you should NOT see what you type)(if you are novice with RS232, go to 8052.com and download Jon Ledbetter's "RS232 guide" http://www.8052.com/faqs.phtml?FAQ=120308 ). Don't forget to check if the cable's has not an intermittent fault (e.g. broken wire) (including GND!).

2. verify your 'V51 is running (this is a standard check independend on IAP and particular derivative): check VCC and GND, check XTAL running (using oscilloscope), check RESET is not hanging high but will pulse when power is cycled or RESET pressed. I hope you have a decent reset generator and not an RC one. Be sure to measure directly on the pins of the 'V51.

3. Do the "terminal only" check: run a decent terminal, press and hold "U", reset the chip - it should start echoing. Use 9600 baud or so. If no echo, find my "unsoftice" and try following the instructions there.

This all written hastily, I don't have more time now. Try to figure out yourself, also from searching on this web and 8052.com, what's what.

JW

PS: Andy: shouldn't there be a faq for this?

Maybe a typo? T51Prog?

JW

In the datasheet and/or user manual of LPC9xx.

JW

PS: Nice poll :-) My wote went for "a". :-P

[not]

Can you please check it also with other chips?

PL2303X was found to be not working satisfactorily http://www.8052.com/forum/thread.phtml?thread=97853 - this has to do with the way how the '51RD2's bootloader sends out the characters (with no space between them); so also the crystal, associated level converters and cabling will influence the chances of this gadget working or not.

[added later] A similar, but PL2303HX-based cable was found to be working OK.
It appears, that there are different versions of the PL2303 with different suffixes; and also different revisions of the same suffix chip. Also, the reason of non-working of certain revisions might perhaps be different than the chip itself, so no definitive conclusion can be drawn at the moment based on "PL2303-based" alone.

JW

Great post! - where are the markings on this forum to give it an "Excellent"? :-)

Only a few comments.

I would be a bit more specific with 10. - "ensure common ground between MCU's RS232 converter and PC ground is present - a broken GND in cable is a pain in ***"

Before checking for U on oscilloscope etc., a simpler/faster way is to remove the chip (if socketed) and short Rx/Tx at the socket (if it's a "classic" quasibidirectional '51 output, it can be shorted without removing the chip but this might not be true for the LPC's, I don't know) - any character should be echoed (and if short removed, the echo should cease). A "local echo" in the terminal switched on should exhibit double-echoed characters during the short.

If the echo from the device is present but different from "U", don't panic, reset (switch off/on power) the micro and retry - you might need to repeat it several times (I'd give it up and go for troubleshooting after 5-6 attempts (at a reasonably low speed - say 2400)). This is the same when the "decrease speed" window in FM appears. Due to how the autobauding works, chances are, that it autobauds to a slightly different speed than expected. <shameless advertisement>There is an excel chart on my pages calculating the probability of an autobaud going wrong for different crystal, baudrate and assymetry on the cable/converter. </shameless advertisement>

I would also add two device specific hints, although by the time one reads this it might be late...:

[P89V51RD2] - double check you have not selected P89C51RD2 by mistake - in case you did, you might be in softice mode, <shameless advertisement>google for unsoftice </shameless advertisement>

[P89C51RD2] - if you specified full chip erase, be patient until it finishes - this might take looooong (say, 30 seconds). If you disconnect power meantime, you'll most probably end up with the "bootvector lost" problem.

Finally one request.
Item 17 says that in case of long timeouts and something goes wrong, FM might "freeze". Wouldn't it be possible to come out of this "freeze", e.g. using Ctrl-C or similar?

• micro not working at all
  
  
  
  • no or bad power (check with DMM and/or oscilloscope)
  • no reset (throw away the RC reset if you use it) or "hanging" reset
  • oscillator not working (check with oscilloscope)
• bad method of entering ISP - check with the appropriate datasheet/appnote
• faulty RS232 connection - check by pulling the micro from socket (I hope it's socketed) and short Rx and Tx - in terminal you should see echoed characters
• "bootvector loss" problem - search on this forum

What is the history of this chip? Did you already attempt to program it? Did you run it in a board with inappropriate (=RC) reset?

Jan Waclawek

Did you wait until this operation finished?

Jan Waclawek

They are listed at the beginning of the non-H version datasheet.

Basically they are three:
- different 6clk/12clk switching
- different organisation (smaller blocks) of FLASH
- different programming

However, both the H and non-H are AFAIK obsolete.

JW

Even if you wouldn't be able to program block1 on the parallel programmer - which I doubt, I believe there must be some "trick" how to achieve it - maybe they map Block1 to above 0xFFFF? try consulting the programmer's manual, manufacturer's website etc. - if you program the "upgrade" into block 0, upon running it programs the bootloader to block1.

Have fun!

JW

Andy,

I apologize.

Jan Waclawek

Andy,

Isn't this related to the "yellow label V51RD2 won't erase" problem (http://www.esacademy.com/software/flashmagic/forum/read.php?f=1&i=2996&t=2996 and http://www.esacademy.com/software/flashmagic/forum/read.php?f=1&i=3032&t=3032 )?

Can you plese share with us what you have learned on the topic of bootloader changes so far? Does NXP already sell chips with factory-burned bootloader version other than 4 (or 5)?

I have found this note http://www.standardics.nxp.com/support/documents/microcontrollers/pdf/tn06007.pdf , and it says (under Remarks):

1.  Within a short notice a new release of the ISP/IAP software which emulates the C family ISP/IAP .
The customer can download and update the software in the field.
2.  P89V51RX2 with a bootrom program revision 7(for RD) and revision 3 (for RB/RC)  or later will have
the option to skip the startup delay of 400msec and to force the ISP mode from every selected IO
pin. This can be programmed via ISP. The version number can be read via ISP.

---

I don't quite understand why Philips/NXP is making such a hassle around the modified bootloader; and, more importantly, I don't understand the mysterious atmosphere they make around it. Why can't they simply publish what they do in a decent way?

The modification I present on my website was made in one evening, complete with "reprogrammer" and some info, without having access to actual sources. OK I admit it was only a small change and they might be planning for more thorough changes, but I don't quite understand why does it take them months to accomplish (I have the document referenced above in v0.5 dated June 2006 which already announced the new bootloader - what have we now, November?).

But what makes me completely crazy is how they (don't) document any of it... (plus that insane website, it's always a challenge to find any relevant info on it).


Sorry, I know it's not your nor ESAcademy's fault...


Jan Waclawek


PS. Shouldn't  FM check the bootloader version before it attempts to use a newly introduced feature?