Messages

If I am not wrong Mr. jan then does it mean that the code in Block0 and when Try to perfor the IAP at that time it is overlayed by the IAP rotuines...

so rather performing parallel proag.. can we load the code directly from address 2000H in the flash???

I don't understand your question.

Can you please rephrase it, perhaps giving more details?

JW

If I understand you right, you want to prevent further ISP programming altogether.

If this is the case, you should perhaps update the bootloader to the newest V7 (not on NXP website, but on the main flashmagic website) and then set to "run user code" - in that way, only parallel programming is possible.

If this is not what you wanted, please describe more clearly.

JW

Hi everyone .,

Hello,

Im using P89V51RD2 and we have designed this board, wen i start downloading my hex code flash magic is showing RESET TO ISP MODE in RED colour so wen i give 5V to PIN 4 or externally plug and play its not downloading its jus simply showing attempting to connect in bottom..... i dono wat to do ......

As Erik said above, please either tell us EXACTLY the package, or, better, refer to the pin's NAME rather than number.

You should perhaps read Andy Ayre's very extensive troubleshooting guide: http://forum.flashmagictool.com/index.php?topic=3273.0 , and also the 'V51Rx2 - specific remarks: http://forum.flashmagictool.com/index.php?topic=3232.0

this is first time im using PHILIPS         

Actually, it's already NXP... :-)

Jan Waclawek

If you run IAP functions from Block0, they work on Block1.
In other words, you have overwritten parts of your bootloader.
This is why you should use the bootloader's IAP API to get portions of Block0 reprogrammed (the bootloader runs from Block1 so it can modify Block0).

You need to reprogram the bootloader in a parallel programmer now.

Jan Waclawek

PS. You should better come to 8052.com forum to discuss this, as this is not really FlashMagic related.
PS2. What, finally somebody believes me that for documentation on Philips/NXP chip one has to go to SST...

I am calculatin the sector like. if i have to erae the sector strating from 0xd000. then decimal of 0xd000 is 53248 and divide by 128 means 416 so sector no. is 417 and whose hex is 0x1A1. but i cdnt..

I think you misunderstood the meaning of "sector count" - simply load dptr by 0xd000 and perform the IAP call...

JW

If the bootloader is well written then there "may not" be any dependence on reset values (who knows how well the boot loader is written???).

Joe, epeng,

the ISP code is freely available from NXP as the code appendix to the "adding your code to the bootloader" appnote (the name is just a guesswork out of my head, please take time to find it yourself on the nasty NXP website :-) )

Nevertheless it relies on the internal IAP code, which appears to be hidden...

JW

I really appreciate everyone's help... Still, the old version of FlashMagic (I don't know which) worked fine.

Keit,

I think Andy Ayre is the only one who will give you a definitive answer (and he seems to absent from this forum for a week or so so he might be on vacations); but meantime, did you read this recent thread? Isn't this the same problem than you are fighting?

JW

[can]

Tom,

see my answers in the 8052.com forum http://www.8052.com/forum/thread.phtml?thread=142191

PS. I said above the RC-reset problem can be excluded in your case, haven't I? (how is the confused smiley? :-) )

Do you mean, they don't reply anything, or they reply garbage?
In the first case, you might have the infamous "bootvector loss" problem... What sort of reset circuit do you use?

No reply at all. Not even garbage.
Using a MAX810 for reset.

No reply at all indicates that the bootloader is not working. Now there are a whole host of possible reasons, including complete malfunction of the part or some of the surrounding circuitry...

I assume you observed all necessary conditions for the bootloader entry (including P2.6&P2.7 state for the H suffix parts - btw. are the unresponding parts of the same suffix?)

Well, the RC-reset issue (which IMHO is still not quite proved in this particular case) can be excluded; nevertheless, this still can be the "bootvector loss" case. The P89C51Rx2's bootloader entry method is defficient in that sense that it is easy to get to a state from where there is no return (this is why I see the 'V51Rx2's solution superior to this; even the Atmel's AT89C51Rx2's bootloader behaviour is more consistent in this regard). Unfortunately, I know of no simple method to verify this is the case, except putting the chip into a parallel programmer (or a circuit where it could be run from an external code memory) - can you pull the parts off the board?

JW

Well it looks like we're not out of the woods yet. This latest build had 19 systems that wouldn't program. Out of those 19, I was able to program 5. Some were RB2HBA and some were RB2BA. Dropped the baud down to 19.2k (accidentally did one at 7200! Sheesh, what a long time that took!)

Tom,

If you follow Andy's recommendation, autobauding at a LOW baudrate (don't be shy to go as low as 2400) then switching to higher baudrate using the dedicated ISP command, you will gain both reliability in autobauding and high programming speed.

My scope says that the ones that don't program aren't replying to the first "U" that FM sends.

Do you mean, they don't reply anything, or they reply garbage?
In the first case, you might have the infamous "bootvector loss" problem... What sort of reset circuit do you use?

It's interesting that my PC seems to be able to program more boards than the laptops & PC's used in the production area. Could that mean that those RS232 level shifters are adding skew to the characters to where the RB2's don't recognize them?

Yes. If you have a look at the excell sheet on my webpage I mentioned above, you can play with the value of skew/assymmetry and see how it influences the probability of correct autobaud at various baudrates.

Actually, once you have connected your scope, did you measure the skew/assymmetry, as present on the '51Rx2's RxD pin?


JW

Tom,

No, you are not. Please re-read Andy's post carefully. You (or FM rather than you ) will only use the low baudrate for autobauding, after that it can switch to the high baudrate, that to be actually used during the lenghtiest operation - programming and verification.

JW

Joe,

I don't understand, do you think the poor guy corrupted Block1 using ISP?

Jan Waclawek

Andy,

It appears to me that TomP is able to autobaud at 57k6, but not reliably enough.

TomP,

Please have a look at my webpage (www.efton.sk), there is somewhere a "autobaud error" page - it's an excel chart, showing the probability of errorneous autobaud with various baudrates, crystals and assymmetry in your RS232 chain. Although it says 'V51RD2, the autobaud routine is IIRC the same in the 'C51RD2, too; so this should be valid for your case. Some combinations are better than others, but the lower baudrates come out generally better than the higher - that's why Andy's recommendation to start with 9600 or lower, shall work better than anything else.

JW

Well, you have an amazingly old datasheet... Any newer DS than version 1 specifies the IAP command for sector erasing - and you don't need to update the bootloader for this purpose.

Jan Waclawek

[loader]

I agree with Andy - you most probably confuse bootloader (which is a program stored in ROM) corruption with bootvector (which is a single FLASH byte) corruption.

If you don't have access to parallel programmer, and are willing to experiment, are not afraid you might destroy your chip, and have a board where you can run the '51 with completely external code memory, I can send you a short code which might restore the bootvector and status byte. However, you will do that on your own risk - I tried it only on a H-suffix chip (P89C51RD2HBP).

Jan Waclawek