Messages

I did and just as I was starting to compare the working waveforms to the non-working, they started working!
Disconnected the scope & it still works!?!

I'm guessing that somehow in testing all of the options (T1, T2, times for instance) that some of the settings didn't get returned to their proper state.

All is well now. Thanks.

tom

Update: tried to fix this by changing the Compatibility Mode to "Run this program in compatibility mode for: Windows XP (Service Pack 2)".
Did not work.

tom

We have an in-house designed programming board that uses RTS & DTR to ISP several of our products that use the 89LPC932A1. There's been no issues with it until recently. I just "upgraded" to a new PC that has Vista-64 versus the old PC that ran XP Pro. The problem is, now FM doesn't work with the on-board serial port, or the add-in serial card (Rosewill RC-301)! It gives the dreaded "autobaud" failure message.

I can take the programming board connected to the product board over to the old PC and check the Device Signature as a quick test, with no problem. I've scoped everything out on the new PC and it looks like there is some strange timing issues between RTS & DTR, irrespective of which port I try. I did download and install the latest driver for the Rosewill card, but to no avail. I have the latest FM: 5.69.2060.

So has ANYBODY programmed an LPC9xx part using the RTS/DTR method under Vista or Win 7? (We tried it on the IT guy's PC with Win 7 and if failed there too).

Note: I have programmed an LPC1114 with the same new PC and FM with no problems, but of course, this does not use the same interface as an LPC9xx.

Thanks.
tom

I've got FM connected to an LPC1114/301.

The Erase Flash menu gives the option to "Erase All Flash+Code Rd Prot".

I understand that "Code Rd" refers to the Code Red LPCXpresso stuff, but what exactly does "Prot" mean? Protected?


tom

Try CONFIG(0xsspp) where ss and pp are the 8-bit values used in the 0CH hex record to configure the device. For details of the 0CH hex record see the PDF file that came with the bootloader. For example:

Code Select Expand

CONFIG(0x01A7)

should program the device to execute user code if P2.7 = 1, else execute ISP.

Andy

The pdf (bootcode_new_LV_ver_71.pdf) says that this is only for the RD2 versions.
Will this work on RB2 & RC2 parts too?

tom

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,

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!

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

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

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

Tom

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

I've got code that fits in Blocks 0 to 2 of a 922. Somehow (don't know how), the security bits for Block 3 got set. When I reprogram the software, with the security bits cleared for all blocks, the Block 3 bits are still programmed.

Does this mean that FM programs only the security bits for the blocks that have code in them? Or am I missing something?

Thanks.

tom