Messages

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.

Furthermore 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.

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.

Just out of curiosity: Atmel AT89C51RD2/ED2?

Jan Waclawek

I can program and verify the micro, so I'm sure that I write correctly the code but wen I try to restart the board this don't start.

What does this exactly mean? How do you verify your board "don't start"? What is the expected behaviour and what are the symptoms? Is there any serial (RS232) connection to the board active while it is being reset? Don't you have a reset circuit and/or /PSEN connected to RS232?

As this is not exactly a FlashMagic problem, you might have receive better help at the 8052.com Forum.

JW

You then want to check your production parallel programmer  (perhaps contact its vendor) if it is capable of programming both the boot block together with the application block, and how to load the hexfiles into it.
---
One of the options how to approach the "no wait for autobaud upon reset" problem would be to disable the bootloader completely and write your own bootloader into the application itself, using IAP; or simply calling the original bootloader from the application upon appropriate stimulus. You still want to keep most of the bootloader as it contains also the IAP routines themselves; but you can safely overwrite the first few bytes to perform software reset (causing also switch to application block) immediately as the first instruction in the boot block.

I have already sucessfully modified the bootloader - see my webpage - and you can contact me directly if you want to discuss this further.

Jan Waclawek

In theory, both are possible, but you first need to understand how the "bootloader updater" works. You can for example disassemble the "updater" and also try to work out of the hints I scattered around both this and the 8052.com Forum.

Nevertheless it might be easier simply to develop a command-line based tool (maybe as simple as a .bat file) performing all three operations via the command-line interface of FM.

JW

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

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

Mihir,

I don't remember I said anything about lifting p3.4 in the http://www.efton.sk/t0t1/unsoftice.htm description. I admit it's not trivial, but not that complicated, either.

Philips/NXP is aware of the problem and the version 5 of the bootloader solves this (as does the newest version 7, available only on Flashmagic site). However, it does seem they still ship the microcontrollers with version 4 of the bootloader.

JW

[V]

Assuming you are talking about P89V51RD2, it's in the "main" window, a tickbox with a somewhat misleading name, "Prog Clocks Bit" (at least in version 3.61 I am currently using).

JW

This Forum is inteded for FlashMagic issues, and not general '51/LPC9xx questions; hence it's not likely you will get a relevant answer here.

You should perhaps consider posting the same question on the 8052.com Forum.

JW

http://www.8052.com/forum/thread.phtml?thread=145736

Can you try a different USB-RS232 adapter? Or a true COM port?

Have you also read the troubleshooting guide (http://forum.flashmagictool.com/index.php?topic=3273.0 and http://forum.flashmagictool.com/index.php?topic=3375.0)?

JW

hi...

1) Where can I get information about bootloader. i.e. How to write my own bootloader and how to program it etc......
2) How can I write my own IAP.
3) what does mean encryption of the Hex file..

Where can I have information about all this data..
Now I am very Excited to know all this thing....

This is an extensive topic and you shall do your reading.

1. The details on how to reprogram the boot block (block 1) are not published by NXP. I worked it out based on the similarity with a SST chip (I dare to say, it's the same chip). Please go through the archives here and on 8052.com to get the details. But, this is maybe the longest way to go. First, I'd recommend to start with familiarising with the IAP interface provided by the default bootloader - see the datasheet. Learn to reprogram a single sector (128 bytes) in the user block using the IAP, first.

2. How to write a bootloader in general: you need to establish a protocol (or simply take the same protocol as the default bootloader uses), write a receiver for the packets, process the received packets, program (burn) data accordingly (see item 1 above), transmit response. Optionally, perform autobauding at the start (not necessary for an application with fixed crystal frequency).

3. When you mastered item 2 above, you can try to encrypt the transmitted data - for inspiration, read appnotes "DES bootloader" and "AES bootloader" from Atmel. Although AVR-specific, the underlying principles that apply for any microcontroller, are well explained there.

JW

I see no reason to 'protect' object code.  It is, at least, 5 times faster to recreate code from scratch that trying to do it from a disassembly.

Ooooh, you are very mistaken, sir.

But let's not discuss the topic in all it's width, we did this so many times. Let's just concentrate on this very case.

Consider the following:
1. I make product A consisting of some hardware H, a microcontroller M and firmware F. I sell it to X, Y and Z for $$$.
2. Having earned some money, and being enthusiastic enough, I work on improvement of firmware and produce firmware F1. It took me some time to arrive at this moment, so I want to reclaim some of my expenses. I decide to sell the upgrade firmware for $$ and expect that at least X and Y will buy it; that's 2$$ to pay my bills.
3. X buys the upgrade (binary) for $$, but he knows Y and Z well and sells them the upgrade for $ each.
4. X starts cloning the hardware into H', to sell for $$ apeace to P, Q and R; with the fresh new upgrade F1 bundled. I sell no more hardware H for $$$ nor upgrade F1 for $$, and have no hope of future sales even if I produce improved firmwares F2, F3 etc., as they get cloned as easily as F1 did.

JW

[not]

My autorized person can perfrom the ISP by knowing the serial Number..
But unautorized can't perform the ISP unless resetting the serial number. but once it will be reset unautorized can perform ISP...

Your authorised person does not need to reset the serial number, it's enough to get the serial number verified. (Or, alternatively, after having reset it, he can write it again).

But, of course, once he knows it, he can reset it, too, leaving the device "open". But then, if you allow your authorised person to  reprogram the device, you are giving him the hexfile anyway, so he must have some degree of confidence from you.

Of course higher levels of protection can be established, too; but you then need to either rewrite the default bootloader (it's possible as it is in Flash, too); or to write your own, using IAP. You can then go even for encryption of the hexfile etc., all sorts of paranoia... :-)

JW

But, what exactly do you want to prevent the unauthorised person to do?
If the password is not set, he cannot do anything (except autobauding) if he does not know the password, can he?

JW