Messages

A replacement bootloader sounds good to me. Is this open source? Is it possible to get it from Philips?

Thank you for your answer. Although it's no good news, it will help me to live with it and to stop turning around trying to debug our soft where there is nothing to debug.

Thanks a lot. Of course this information explains many things I was trying to figure out during hours. Thank you.

There is a 'normal' power-up mentioned. I thought that I could prevent the bootloader from getting active by setting the BSEL flag. How to explain that the bytes are still altered? The bootloader gets active in all cases? Is there no way to inhibit it?

Thank you again for your help.

I am evaluating this device for direct replacement of the Intel D87C51Fx in an older design. This design uses a backup battery that shall be replaced by the Philips device's flash.

Our software calculates a checksum over the internal RAM (excluding the first register bank and the stack area) before setting the PD (Power Down) flag. The same calculation is done immediately at start-up and the comparison of the two checksums allows reliable detection of RAM data loss.

Unfortunately this same program doesn't work with the P89V51RD2BN, since the internal RAM data at address 3Bh and 21h are altered somwhere between the two checksum calculations.

I figured that probably the Philips Bootcode (V4) uses some RAM when doing autobauding. Therefore I added some code to set the BSEL flag in the power down procedure right before setting PD. It seems that the device boots directly to user code (since FlashMagic is not able to connect), but the mentioned memory is still altered.

Does anybody have any explanation to what is happening? What are the first steps the device is doing after Reset?

Again: The same code works on an Intel D87C51FB1 without the memory beeing altered.

Hi,

I would like my application store parameter data in the flash of a P89V51RD2. How to do this?

Thank you for your help.