P89C51RB2H baud rate bug?

[TomP]

We've been having difficulty (for some time, I just found out. Thank you Manufacturing for keeping me in the dark!) programming a product that has a P89C51RB2H on it. We get the "Unable to connect at specified baud rate..." message. The crew doing the programming sometimes have to try programming it multiple times (5 is not uncommon) to have FM get a valid reply. At first I thought it was because P2.6 & P2.7 were unconnected, but tying them high doesn't help. So I drag out the scope and look at the serial data. Our RB2H has the standard 11.0592MHz crystal (scope confirms the crystal is good), and we're trying to communicate at 57.6K baud.

Here's the weird part: The baud coming from the RB2H is measured to be 52.9K?!?

Is this because FM sends the crystal freq as 11MHz? I can't find boot source code, so I don't really know what they use for the baud rate clock.

Sometimes it sends back 'u' in response to the 'U'. Is this some kind of error message? Another reason I'd like to see the boot source code.

Lower bauds work better, but still not consistently. Results can vary from board to board.

Ideas? Suggestions? Chocolate cookie recipes?

Thanks!

tom

[Andy Ayre]

I would say 57.6k is high for 11.0592MHz.

After reset into the bootloader the device determines the baudrate the PC is used by measuring the bit times in the 'U' it receives. It then programs the UART to use this measured baudrate. The higher the baudrate the harder it is for the device to accurately measure the bit times. The device then echoes back the 'U'. If you get something other than a 'U' then the device has failed to measure the baudrate correctly. A 3% error is roughly the maximum you can have in the baudrates between the PC and the device.

Flash Magic doesn't send the crystal frequency until after the autobauding has completed, and the device only uses the crystal frequency to determine programming times for the flash memory.

If you are having a problem at 9600 baud then I would be concerned.

If you enable the high speed communications option in the advanced options, then after autobauding at a slow speed, say 9600 baud, Flash Magic can calculate the timer 2 reload value to set the device precisely to a higher baudrate. Flash Magic will then switch also to that baudrate and communications will continue. This provides the best of both worlds - reliable autobauding followed by faster data transfer. However 57600 baud may still not be possible at 11.0592MHz.

Andy

[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

[TomP]

Thanks guys. It looks like we're stuck with going to the lower baud rates.

Tom

[Jan Waclawek]

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

[TomP]

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!)

My scope says that the ones that don't program aren't replying to the first "U" that FM sends. 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?

Not sure what to try next, so if anyone has any ideas, shoot 'em to me!

tom

[Andy Ayre]

It sounds like an electrical problem to me. Also it's important to make sure the correct device is chosen in FM. The RB2BA has a different flash block arrangement to the RB2HBA.

Try checking the voltage levels on the RS232 side and check the 'U' at the RxD pin.

If you are using USB to RS232 cables then those are often problematic.

Andy

[Jan Waclawek]

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

[TomP]

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.

That helped some of the boards work. I'll have to remember this option.

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.

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?

I'll take another look at that, but I recall that it looked pretty good. Besides, the 232 drivers are not on the product boards, but on the programming fixture. So if they were adding skew I would think more of the boards would have programming troubles.

In the Advanced Options/Communications tab of FM, what effect do the 6 Clock/12 Clock settings have?

Thanks for the help, by the way...

tom

[Andy Ayre]

In the Advanced Options/Communications tab of FM, what effect do the 6 Clock/12 Clock settings have?

That is used for calculating the timer 2/baudrate generator reload value in order to configure the device for a precise higher speed baudrate.

Andy

[Jan Waclawek]

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

[TomP]

Jan,

Regarding the P2.6 & P2.7 pins: do they need to be pulled high, or can they be unconnected, which will cause them to be pulled up internally? One of the data sheets states that either will work, but I can't remember which part. I did try pulling them up and it did not help.

Why can't you exclude the RC-reset issue in this case? The waveforms look perfect w.r.t. +5V power and reset. The MAX810 is pretty stable.

I thought I had read up on all the issues on this, but maybe I missed some discussions. Are you saying that the boot vector or status byte can get corrupted due to an incorrect reset?

I've sent 5 boards to our contract manufacturer to pull the 51's off, and I'm purchasing a hot air rework station for use here!

tom

ps I like the V51 ISP method too, but we've already got an established procedure in the field and retraining our customers is out of the question!

pps I found the discussion & FAQ on 8052.com that reminded me of the RC-reset issue!

[TomP]

I had our board stuffer take off micro's from 5 boards: 2 had RB2's and 3 had RB2H's.

The results: all 5 had their boot vectors corrupted! Some had the boot vector corrupted also!

What confuses me is that we have a MAX810 reset controller on board! Supposedly much better than an RC reset circuit!

So how do I verify that this is a problem? Is it related to the +5V rise time? Do I have to switch reset controllers?

Thanks.

tom

[Jan Waclawek]

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? :-) )