We have developed a board to program (via ISP - FM) the P89C51RD2.
The board has a USB interface through a FTDI chip and a "normal" RS-232 interface and is used in students labs.
After some time we "run out" of P89C51RD2.
I read a post in Keil forum, http://www.keil.com/forum/docs/thread10439.asp by erik malund, about the replacement part, since I cannot manage myself in the NXP site. In that post the 89V51RD2 was mentioned. Placed an order ... waited a long while ... and tested the parts to no success at all.
Found information in this forum about the new bootloader and I do suspect that the FTDI chip is generating some garbage at power on that simple makes the 89V51 to go crazy.
Also this afternoon tried to program the parts with the v7 bootloader using a parallel programmer, unfortunately I wasn't able to program more than a few bytes (around 300) in block 1. Could be adapter related or programmer problem, will have to check it again.
My questions are, if I manage to program the v7 bootloader will I be able to configure it using the "true RS-232" port using FM in order to be able to enter ISP through pulling a pin high during reset?
Should I forget about these parts and buy the 89cv51rd2 instead?
Is there anyway of parallel programming the part in order to change the bootloader to enter ISP directly if pin P2.x is pulled (low or high) during a reset?
Thanks in advance
I do suspect that the FTDI chip is generating some garbage at power on that simple makes the 89V51 to go crazy.
You do not state which ftdi chip you use, but the Vinculum babbles its little head off after you reseet it.
Erik
It is the FT232R. After trying and "erasing" a few bootloaders, I decided to read a little in the forums ... too late to change the orders, unfortunately.
I even tried to press and hold the reset button during the power-up of the board. Used FM (it does send trails of 'U''s) and release reset after, the part sends something back, but the only speed where I got something meaningfully (3 bytes that look alike the Device ID) was at 115200 bps. Them it simple "crashes" ... bootloader is erased or whatever.
I will try to parallel program the device again tomorrow.
But the question still remains, is it possible to replace the bootloader by one where the ISP mode is set by pulling a P2.x pin during reset?
Regards
P89C51RD2 are if not already going obsolete.
P89V51RD2 has significant difference in the programming of P89V to the P89C.
P89V looks at the UART Rx data line after reset (if 'U' char then invoke bootloader).... where as P89C uses /PSEN and RESET
Yes - It is possible using a profesional programmer to reload the bootloader in to block1 of a P89V51 (block0 is user code).
If your first bit of code is an NoTouch algorithm then yes it is possible to invoke the boot loader by looking at GPIO activity.... BUT.... why would you if you can invoke the bootloader after reset by sending 'U' char's to the UART Rx.
Joe
Yes, the latest bootloader allows you to configure a pin for ISP entry. However I believe you have to specify that configuration via ISP.
Andy
P89C51RD2 are if not already going obsolete.
P89V51RD2 has significant difference in the programming of P89V to the P89C.
P89V looks at the UART Rx data line after reset (if 'U' char then invoke bootloader).... where as P89C uses /PSEN and RESET
The development board was "built" for P89C51 and uses the FTD232R chip. It has the advantage of allowing students to use their personal laptops.
Unfortunately, the FTD232R generates a bit of garbage at power-up and I'm using the clock output as the xtal2 for the microcontroller, so in order to make the 89V51 work with the board I'll need to reprogram the bootloader.
Yes - It is possible using a profesional programmer to reload the bootloader in to block1 of a P89V51 (block0 is user code).
Finally managed, needed a Capacitor between Vcc and Vss, in order to my programmer to work.
If your first bit of code is an NoTouch algorithm then yes it is possible to invoke the boot loader by looking at GPIO activity.... BUT.... why would you if you can invoke the bootloader after reset by sending 'U' char's to the UART Rx.
Due to the limitations of the board we use (FTD232R chip generates garbage and bootloader "gets confused").
Edited ... Thanks for the answer Joe
Quote from: Andy Ayre on January 16, 2008, 08:14:47 AM
Yes, the latest bootloader allows you to configure a pin for ISP entry. However I believe you have to specify that configuration via ISP.
Andy
...
Ok, those are good news.
I downloaded the v7 from falshmagic forum.
Can one of you supply me a .hex or .bin file to parallel program the 89v51 with the configuration already set (any P2 pin high or low)? Know that I'm being lazy but it will save me the work of building a prototype that uses a true RS-232 port.
Thank you for the reply
Sorry, the bootloader comes from NXP, not us, so we don't directly support configuring it.
Andy
Quote from: Andy Ayre on January 16, 2008, 01:09:49 PM
Sorry, the bootloader comes from NXP, not us, so we don't directly support configuring it.
Andy
No problem, I will parallel program the parts with the bootloader from NXP site, there is a version there to upgrade to v5 by parallel programmer. I will make a prototype board this week in order to upgrade by ISP to v7 and them program by FM the ISP entry by GPIO. Hopefully I will them be able to "copy" the bootloader to the rest of the chips.
Cheers thanks for the good news feedback. Please to see you go it working..
Since there is some Vdd, Vss or data "garbage" on the FTDI232 are you able to clean it up with decoupling and filter caps.
It should be well noted in the forums that USB to Serial converts give trouble..... have you considered stretching the times of the Reset and 'U' character from the config in Flashmagic?
Search the forum fir "USB" you are bound to pickup some comments.
Me..... I made sure I got a laptop with RS232 ;-)
Regards
Joe
just a suggestion
while I am not familiar with your ftdi chip, how about a switch or jumper that hold the ftdi in reset. If the chip require CTS like the vinc, then configure the board so that signal is false during reset/bootload
Erik
Quote from: erikm on January 17, 2008, 06:13:52 AM
just a suggestion
while I am not familiar with your ftdi chip, how about a switch or jumper that hold the ftdi in reset. If the chip require CTS like the vinc, then configure the board so that signal is false during reset/bootload
Erik
One of the problems is the FTDI chip. In our board we did not use the reset neither the CTS RTS lines in order to automatically enter the ISP mode. We used a jumper in the PSEN with the reset ... it worked fine :(
The FTDI chip only generates the oscillator after detecting communications with a PC ...
The other problem is the power, using the USB to power the board doesn't seems to work properly with 89V51 (in my case!!!).
Finally, I have to say that the new part is disappointing. It is surreal that the microcontroller enters in ISP mode and even worst it cleans up the internal flash memory contents (part of the original boot code is placed there) before making sure that a proper communication is achieved with the PC.
I finalize by giving my thanks to you all for your suggestions and congratulate Andy for a very nice tool. One of the reasons I choose the P89C51RD2 was due to the simplicity and efficiency of FlashMagic.
You might want to look at the 89CV51Rx2 devices. I believe they don't execute the bootloader on every reset. Thanks for the kind words.
Andy
Hello jcabral,
although it's hard to judge without seeing your design first, I think the problem is that the P89V51RD2 gets resetted spuriously due to insufficient VCC.
You are trying to power a 5V part from the USB power. Although the nominal voltage at USB is 5V, the tolerance of it is high, and even that is often violated - on a typical USB endpoint it is not rare to have less than 4.5V. Nevertheless, you are NOT supposed to use the 5V of USB to power 5V parts; you are supposed to power only 3V parts in a typical host-powered USB device through a suitable voltage regulator.
The 'V' part - contrary to the 'C' - has an built-in brown-out detector, and even though the datasheet is unclear about its exact whereabouts, it should cause a reset under an undervoltage condition. This in fact is not a drawback of the 'V', rather an advantage - the 'C' under insufficient VCC might have run crazy.
I also suspect the 'CV' would have the undervoltage protection, so that is not really an option. You should either provide valid 5V to the 5V parts, or use the 3V version of the part.
I might be wrong, of course.
Jan Waclawek
Hi Jan,
The board has a DC power in as well. With the P89C it worked with the USB power only ...
What I found very strange is that the bootloader "destroys" itself.
I have been looking for other manufacturers and I found that some have new bootloaders similar to this one, but they still keep the hardware ISP entry mode.
Regards,
jcabral
And did using the DC power separate from USB alleviate your problems?
---
I don't quite understand what you mean "the bootloader destroys itself". Please comment.
JW
Quote from: Jan Waclawek on January 23, 2008, 12:18:01 AM
And did using the DC power separate from USB alleviate your problems?
---
I don't quite understand what you mean "the bootloader destroys itself". Please comment.
JW
A separate DC power doesn't solve the problem, in order to work I have to make changes to the development board: include a reset to the FTDI chip or include a oscillator based on an external crystal.
The bootloader has code in "user" program memory ... that code deletes itself after determining the baud rate, it does it very well from any garbage generated from the FTDI ... if the chip gets garbage from the serial port or Vdd is not 5.0V, that portion of code is deleted and a parallel programmer is required to recover. Furthermore bootloader v7 is only available for ISP upgrade, only v5 is available from NXP site.
What I will do asap is to modify the bootloader in order to be able to use 40 chips, or redesign a smaller development board with standard RS-232.
For the boards that I have now, and still intend to use (we have around 150 of these), I will buy parts from other manufacturer.
I attached the schematic of the circuit.
Regards,
JCabral
I have been looking for other manufacturers and I found that some have new bootloaders similar to this one, but they still keep the hardware ISP entry mode.
I am a great fan of the no hardware ISP entry mode (I created NoTouch for that reason) and think that Philips did very well with the ISP design of the V chips. However that seems not to be the case for some others so NXP had to come out with the VC series that have hardware ISP entry mode.
SO, if you prefer hardware ISP entry mode get a VC chip, they are supposedly identical to the C (non -H) series re ISP.
Erik
Quote from: jcabral on January 23, 2008, 10:03:47 AM
The bootloader has code in "user" program memory ... that code deletes itself after determining the baud rate, it does it very well from any garbage generated from the FTDI ... if the chip gets garbage from the serial port or Vdd is not 5.0V, that portion of code is deleted and a parallel programmer is required to recover.
The bootloader does not delete itself, nor does it have code in the "user" (application, Block0) FLASH. It is only the bootloader updater (from whichever to version 7) which is programmed into the application FLASH and, after having updated the boot FLASH, it erases itself. But that does not happen before it verifies the new bootloader to be programmed all OK.
However, with erratic power I can imagine any possible scenario. You need to fix that first.
Quote from: jcabral on January 23, 2008, 10:03:47 AMFurthermore bootloader v7 is only available for ISP upgrade, only v5 is available from NXP site.
If you want to program the v7 bootloader in parallel programmer, simply take the updater as downloaded, take out the 0000-1FFF part off it, set the first 3 bytes to zero, and "burn" this into the boot FLASH. Note however, that in this way you will destroy the SoftICE code (the v5 bootloader programmed in parallel programmer into boot FLASH will do the same). If you want to preserve that, you need to read the boot FLASH first, store 0800-1EFF of it - that's the SoftICE part, concatenate it with 0000-07FF and 1F00-1FFF of v7 (zeroing the first three bytes), then program the whole back into the boot FLASH.
Quote from: jcabral on January 23, 2008, 10:03:47 AMWhat I will do asap is to modify the bootloader in order to be able to use 40 chips, or redesign a smaller development board with standard RS-232.
For the boards that I have now, and still intend to use (we have around 150 of these), I will buy parts from other manufacturer.
Just out of curiosity: Atmel AT89C51RD2/ED2?
Jan Waclawek
Note that the bootloader updater is designed to work with the corresponding feature in Flash Magic. Choose Update Bootloader from the ISP menu.
Andy
Quote from: Andy Ayre on January 28, 2008, 07:34:25 AMNote that the bootloader updater is designed to work with the corresponding feature in Flash Magic. Choose Update Bootloader from the ISP menu
Hummmm... Does this meant that there is any sort of magic performed by FlashMagic, other than "burn" the updater as it would any other application, then run it and re-autobaud?
Jan Waclawek
No, but it's not necessary to modify the hex file so is a bit easier than using a parallel programmer.
Andy
Quote from: Andy Ayre on January 28, 2008, 11:11:23 AM
No, but it's not necessary to modify the hex file so is a bit easier than using a parallel programmer.
Oh I see, thanks Andy.
Nevertheless it seems that some users do prefer parallel programming of the bootloader update, and possibly with the "bootloader entry on pin" option switched already on - I know it's beyond FlashMagic, it's just the defunct (or barely functional) NXP web and forum why these question gets asked here - there was an another separate thread about this topic recently.
Jan Waclawek