Messages

But why, you can encrypt the data and include the decryption routine into your "updater".
You can get inspired by the "des bootloader" adn "aes bootloader" for AVRs by Atmel:
http://www.atmel.com/dyn/resources/prod_documents/doc2541.pdf
http://www.atmel.com/dyn/resources/prod_documents/AVR230.zip
http://www.atmel.com/dyn/resources/prod_documents/doc2589.pdf
http://www.atmel.com/dyn/resources/prod_documents/AVR231.zip

Have fun!

Jan Waclawek



Post Edited (04-29-05 22:51)

Bootloaders in FLASH - you don't need a parallel programmer to change it. For example, Philips provides an upgrade for P89V51RD2 - you program it into the user FLASH using the old bootloader, then run it, and it reprograms the bootflash while running from user flash.

Jan Waclawek

Sorry, what is "GM"?

And, the version of bootloader/IAP firmware can (should) be easily idetified; if it changes, the user can go to the manufacturers website and check the changelog (and/or errata). Ideally... :-)
With bootloaders in FLASH (upgradable - e.g. T89C51RD2, P89V51RD2 and probably others too) you can also "downgrade" if needed.

Jan Waclawek

1. The manufacturer (author of the firmware) should be able to tell the stack and other resources requirement (e.g. other used memory, execution time). In fact, this IS a key information for IAP, so I think this information should be in the datasheet/IAP appnote. But, given the number of errors and unclean parts  in the IAP description of both manufacturers, I doubt they will publish this information soon. But you can try their support...
(btw. I cannot find the RD2H datasheet at Philips website...?)
2.In T/AT89C51Rx2, if you use the block write command, it erases/writes the FLASH only once. Note that you cannot write a block across 128B boundary. (I think it_is_ recommended to use block write for multibyte write in the datasheet).
3. Erasing often involves first programming all bits to 0 to achieve uniform charge in the floating gates before erasure. This is usually hidden for the user. If this is the case for Atmel, erasing unprogrammed bits/bytes does increase the wear.

Jan Waclawek

As far as I know Atmel did not publish the stack requirement for IAP, so you may face a similar problem.
Try to come to 8052.com forum with this problem.
Jan Waclawek



Post Edited (04-18-05 05:40)

You have to make sure that the code switching to boot block (clearing FCF.0) and calling the PGM_MTP vector is ABOVE 2000h  - see datasheet.

But this question is in fact not related to FlashMagic, so better write to 8052.com next time.

Jan Waclawek

I just tried the 16MHz crystal and the autobaud works well up to 28800 (the 3.5% error is probably acceptable if small pulse distortion is present - short cable). At 38400 bauds it was unreliable, kicking in perhaps once in 5 attempts - the xls table predicted 1 out of 3 but this really does not matter here.

So you need to go down checking the usual things - get a terminal program, set 9600, press and hold "U" and reset the controller. If it does not start echoing "U"s, check the UART using a loopback connector. If OK, check the cable placing the loopback at its end. Then connect to your board and short together Tx and Rx pin at the controller - this should make no harm and you should see the echo (if the controller is socketed, you can take it out if you don't feel comfortably shorting pins together...).  If the whole datapath is OK, it's time to check the circuit - check power supply directly at the controller's pins, check RESET, check if the oscillator is running (and oscillating at 16MHz...). As a last option, try an another controller - the bootloader can be damaged, and/or missing; and/or the controller itself can be damaged.

Hope some of these will help.

Jan Waclawek

PS. Ufff, I just see Erik's answer, he probably hit it....



Post Edited (03-31-05 05:31)

Again, it depends on the _combination_ of crystal frequency and baudrate (and, slightly, also on the RS232 convertor you use).
And there is always a tolerable error in the setting of the baudrate, say 3% or so.
You can try to set your crystal frequency to the excel sheet at the link I gave and you will see...

For 16MHz, at 9600, you should be on the safe side.

Jan Waclawek

I doubt that as Philips usually don't publish parallel programming specifications.
I recommend you either to find somebody with a parallel device programmer (if you are really a student then maybe some company having a programmer will be happy to program you a chip or two for some small nominal fee or maybe even for free), or to use them as ROM-less.

Jan Waclawek



Post Edited (03-23-05 01:43)

Yes, the X2's are only parallel programmable.

Jan Waclawek

The proper operation of the autobaud routine in P89V51RD2 depends on the _combination_ of crystal frequency _and_ chosen baudrate.
You can always chose a lower baudrate to enable the autobaud routine "catch up" with a particular crystal.  
See and try http://www.efton.sk/t0t1/autobaud_error.htm

Jan Waclawek

Actually, the problem might be not the _low_ crystal, but its particular frequency, which cannot be divided down to the common baudrates (1200, 600).  The 32768Hz divides down (fosc/2/16/N) to 1024 or 512 bauds, which gives an unacceptable error of 14% or so.

Nevertheless, the standard PC UART (16C450-compatible) can be set to baudrates 115200/M (M is 16-bit), so baudrates close to 1024 or 512 can be obtained with negligible error.  (I guess that FlashMagic  does not use these nonstandard rates, as it uses the Windows API calls for full compatibility - not all serial ports on PC are 16C450-compatible). You have to use a terminal program which enables to set custom baudrates (e.g. http://bray.velenje.cx/avr/terminal/) and some means to enter the ISP mode, and then type the ISP commands (intelhex lines) "manually".

You can also try to run the controller at a clock which would divide into the standard baudrates. While crystals/resonators for 38400Hz or 76800Hz are not common, you can probably use an external oscillator (or a frequency/function generator) attached to XTAL1; and I would bet that you can use a wider frequency input to XTAL1 than 100kHz.


It would be nice to hear from either one of you, how you actually solved your problem.

Jan Waclawek

Try http://bray.velenje.cx/avr/terminal/

Direct pin manipulation (and many more interesting features) is implemented also in http://realterm.sourceforge.net/ , but its overall appearance is quite poor and is not easy to use (and has a - documented - flaw in sending binary files, it misses each $1A).

Jan Waclawek

Dear Andrew,

while playing with the P89V51RD2's bootloader, I tried a couple of things with the FlashMagic and noticed this and that - maybe of some help to you.

I am using v2.07 (but I read the release notes and found nothing in the newer versions that would be relevant to the following).

1.  The original poster was confused by the behaviour of FlashMagic, when the chip baudrates to an improper value. With 57600bps  @ 12MHz,  it almost invariably falls into the -5% region, where it echoes back a mixture of "u"-s (75h-s), "5"-s (35h-s) and 15h-s. When this happens while FlashMagic  displays the "Reset Device" window at FlashMagic startup, it displays a window saying (a rather long text, just the beginning here) "Unable to read the security bits..." If I click Retry, the situation repeats. But if I click Cancel, then select (with the same baudrate)  e.g. Read device signature, then the behaciour changes - after the Reset Device window (and improper autobauding) a Unable to connect at specified baudrate window comes.
This is rather confusing.

2. FlashMagic could possibly test the presence of the chip permanently (maybe as an option, with a possibility to enable/disable it).  Helps with experimenting with baudrates and maybe also in production.

3. There is a very nice feature built into FlashMagic - the "HighSpeed Communication" (in Advanced options).  This is a real way to go - autobauding to a safe baudrate, then by direct setting of the reload value switch to the possible maximum. But - oops - disabled for P89V51RD2...
OK, some hacking needed :-)
Having a look into the P89C51RD2 datasheet I see, that the "manual baudrate" works absolutely the same way. Thankfully, FlashMagic is not pecky with the non-matching signature (although... a warning (possibly switchable off) would be perhaps good for safety).
So I autobaud to some 2400bps at the P89V51RD2 setting, then switch to P89C51RD2, set the Xtal value (12MHz) and enable the HighSpeed Communication. First surprise - according to the description in the manual I would expect that the list of maximum baudrates would now contain only the "good" baudrates - but it remains a full list. Never mind, I select 115200bps for maximum (and set properly for 12-clock operation). Starting some communication, it sets 19200bps (displays it for a while at the top bar of the program window; speed confirmed by testing using a terminal emulator)...
Why???
At 12MHz, using a reload value of -10 the baudrate is 38400 bps with error of -2.34%. OK, this might be too high, but then reload value of -13 gives 28800 bps with error of 0.16%! More, the best error for 19200 bps  is at reload value of -20, yielding the same -2.34% as with 38400 bps...
I think, the method of calculation the maximum baudrate should be reconsidered...

4. While playing as described in previous section, FlashMagic in the P89C51RD2 mode sets the P89V51RD2 invariably into SoftICE mode. For P89V51RD2 this is done using the 02 intelhex command. A quick look into the P89C51RD2-s datasheet (dated 2002 Jul 18) - there is NO 02 intelhex command for it! Why does Flash Magic use it then?

5. A minor nuissance: I noticed, that when I select e.g. Read Device Signature (but also some other operations), the window which opens (containing the signature), cannot be closed from the keyboard (no focus on the Close button, ENTER nor ESC does not work) except Alt-F4. Funnily, if I then switch to another window and back (pressing Alt-Tab twice), the focus appears on the Close and both ENTER and SPACE works (but still not ESC).



Jan Waclawek

A summary of what baudrate shall/can be used for P89V51RD2 bootloader is at http://www.efton.sk/t0t1/autobaud_error.htm

I hope this will help Andrew and others in determining the proper baudrate.

Jan Waclawek