Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Nick Daniel

Pages: [1]
1
Thanks for your reply Andy.

I can confirm that the status byte is 0x00 by reading it back but it still takes another go at programming for it to change the boot location.

This is the last of our stock so I have to switch to an Atmel device next time anyway.

Nick

2
We have recently programmed 100 pieces of a product that uses the P89C51RD2HBBD MCU.  This is old Philips stock with date code D0047 G (I think - can't find any doco on this!).
 
On 12 of the boards it was noticed that after programming, verifying successfully then being reset the MCU did not run the application code.  Later investigation showed that the MCU would continue to start in boot loader mode (i.e. boot from 0xFC00).  When power was applied I could communicate with FlashMagic without needing to force entry to the boot loader mode by holding PSEN low at turn on.  With FlashMagic I checked that the device was not blank and verified the code successfully with the hex file.

Using FlashMagic I was able to program the status byte and boot vector separately to the memory space.  I set the status byte to 0x00 and left the boot vector at 0xFC.  After this operation the MCU restarted running the application code.

It is my understanding that FlashMagic would set the status byte to 0x00 after successful programming.

Has anyone seen this behaviour before?  Is there some timing relationship between finishing the verify and programming the status/boot vector bytes that is marginal on these MCUs?

There is a momentary switch attached to PSEN to pull low if ISP mode is needed after programming but I think it unlikely that that this pin was getting a repeatable low glitch at boot up on only these 12 units.

We used FlashMagic 6.77.2724 (this is the free version - we also own a production version license but this was not installed).

Thanks in advance,
Nick

Pages: [1]