Messages

But the 89C/V/CV/51Rx2 family has been discontinued.

The 'CV51Rx family had been conceived as a replacement for the 'C51Rx, isn't it. After years of complaints from the users who were left with empty hands. And it's gone now without replacement. Similarly with the 'C688.

The LPC900 family is in full production and that is modern.

The vast majority of it is gone already. The 5V LPC97x/98x line lasted how long, three years or four? There are 23 LPC9xx in this years' discontinuation list, most of them without replacement; the active parts' list is 27 items long (if I counted them right), including the package variants. I am willing to risk a bet that they all will be gone until the end of next year. And NXP didn't care to design at least a pin-compatible ARM line, once they push them hard now.

I understand the reasons why is it so and I don't complain, just state the facts. Isn't it fair to point out to the frustrated users you see also here that they may be able to find pin-compatible '51s in other compaines' offerings, even if they have slightly different funcionality?

Jan

OK so... discontinued without viable replacement the complete modern '51 derivatives line...

JW

...I hope that parallel programming will solve the problem.

I have a Needham EMP10 programmer and 2 good questions about:
1) Is it possible to program an 89CV51RC with EMP10 parallel programmer that not supports 89CV51RC but 87C51RC microcontrollers?   On the 89CV51 datasheet is written "the flash may be programmed or erased using the parallel method by using a commercially available EPROM programmer which supports this device"

No, and don't even try. Not even the programming pinout and algorithms change from device to device, but also 87 indicates, that it's an EPROM based mcu rather than FLASH, so it most probably would fry the modern chip with applying +12V onto it.

2) If the answer is YES then ...I have the programmer but not the TQFP44 adapter! Needham is passed away and I never found informations to wiring an adapter from TQFP44 to DIP40!

If you would have a modern programmer enough to support this particular chip, the adapter would be most probably just straight, connecting the matching pins between the DIP40 and TQFP44 versions as per datasheet.

Now you either find somebody with such a programmer/adapter, or (not likely I guess) buy such programmer/adapter, or explore the possiblity to migrate to a similar chip (most probably the Atmel variants of the 'RD2).

In the latter case, while it's true that Philips/NXP simply dropped hard the '51 users, you should move the discussion to a more neutral grounds, e.g. to the 8052.com forum.

JW

They look reasonable at least at the first sight. However, "ES" indicates "Engineering Samples" (i.e. pre-production batch) and the timestamp appears to place them to 2007.

That in itself does not mean anything, but I'd be not surprised if these were "pulls" or unpopulated but already programmed parts from a discontinued production, with the bootloader blocked or removed altogether.

As these parts are sadly discontinued for quite some time, I would be not surprised to this become more and more common, see for example also http://www.8052.com/forum

Now the only thing I could recommend to you is to get a parallel programmer and an adapter and try to parallel reprogram the devices. I know the TQFP ZIF has a killer price, but maybe you could borrow it or get somebody to program it for you. It might be tricky to find the original bootloader, though; you might need one of the older chips to read it out.

JW

What is the marking and time stamp on the new devices? Could you post a picture perhaps?

JW

Is this a new lot? What is the time stamp? Couldn't it be related to http://forum.flashmagictool.com/index.php?topic=4085.0;topicseen ?

JW

It sounds a bit unlikely.
Do you use any of the IAP facilities? Do you use the watchdog?
You also might want to double check the VCC decoupling/grounding quality, and also maybe reconsider your reset circuit.

JW

After having exchanged a couple of PMs, Lorenzo sent me the "new" bootloader read out from the new chips.

And, indeed, it is the v7 bootloader deliberately crippled so that it won't accept the 0C command during ISP nor the 04 command through IAP, i.e. the enhancements of v7 vs. v5 as described in the document accompanying the v7 bootloader (setting different bootloader entry methods) are disabled.

Other than that, the code is the same, and responding with version 7. Yes, it IS the same and DOES contain all the code of v7 including the code for setting the various entry methods, except that that code cannot be executed as the check for highest intelhex command is set back to 0B; this is why I used the expression "deliberately crippled".

Draw your own conclusions; I personally am disgusted.

Jan Waclawek

http://forum.flashmagictool.com/index.php?topic=3628.0

As this is not FlashMagic relevant, you might want to consider coming to the 8052.com forum with your question.

JW

As this is not a Flash Magic specific question, you might get more answers coming to the 8052.com Forum.

JW

Depending on how do you define "brick", you might also want to set the boot status bit (BSB) in Boot status register, and the Boot Vector, to their appropriate "factory default" values.

JW

The best is a simple command that doesn't change the device, namely Read Signature.

You have to make sure you are talking to the device at the same baudrate as the autobaud happened.

You can use the terminal interface to talk to the bootloader, however it cannot be in use while performing ISP operations using the rest of Flash Magic. So you would have to enter the ISP commands yourself. I.e. it's not a COM port sniffer. For that look at something like PortMon.

... or simply insert a serial-sniffing "tee" and listen to a separate port(s).

JW

Try to read signature "manually", from hyperterminal. Enter:
:020000050000f9
it should echo the whole line (changing f to F) and append BF. (this is the manufacturer ID).

I'd guess what you see is a local echo or some loopback or the mcu running some application echoing on the UART, and not the bootloader's echo.

JW

Unfortunately Windows only supports specific baudrates.

Well, this is not quite true - any baudrate can be specified in DCB structure used in WinAPI to set serial devices' properties; however, it depends on the particular device's driver how does it interpret. See for example here: "BaudRate  The baud rate at which the communications device operates. This member can be an actual baud rate value, or one of the following indexes."

However, there is no standard method to discover, which particular baudrates are actually supported by a given COM port; on the other hand, there barely exists any form of serial port not supporting the "standard" baudrates, hence they are considered safe to use. If I would implement such a function, I would not expose it in the front window; rather, I would hide it somehow in the "advanced" functions.

JW