Philips PXAG49...

[gmclam]

I am using the Philips PXAG49 (16 bit 8051 equivalent) in a design. The CPU contains internal FLASH and a boot loader; which provides a means to update CODE via a serial interface. It seems that after some use these CPUs no longer want to boot into the loader, and can no longer be programmed in curcuit.

I am wondering if anyone else has experienced this. If so, have you been able to "restore" the CPUs by using a parallel programmer (do you have to redownload the boot code?)?

I'd love to hear any comments.
Thanks,
George

[rshayes]

I have seen a similar problem with an Atmel chip. In that case, the programming sequence started when the reset line was held low. If that pin was programmed as an output, the chip lost the ability to detect the input signal, and could not be reprogrammed using the serial method.

The XA-G49 data sheet indicates that the serial programming interface executes code (the boot loader) located in the top 2K of the flash memory. This memory block can be replaced by 2K of flash memory, probably by setting a bit in a control register. Once this is done, the serial interface is disabled. The data sheet seems to say that the serial programming function can be recovered, but that the parallel programming interface has to be used to reset the bit that deselects this block of memory.

This is discussed to some extent on pages 10 and 11 of the data sheet.

[gmclam]

Yes the ENBOOT flag in the AUXR register can be overwritten. However, that condition is overwritten because of the hardware state of 2 pins at power on, as per note 8 on page 8:

8. The AUXR reset value is typically 00h. If the Boot Loader is activated at reset because the Flash status byte is non-zero or because the Boot
Vector has been forced (by PSEN = 0, ALE = 1, EA = 1 at reset), the AUXR reset value will be 1x00 0000b. Bit 6 will be a 1 if the on-chip
VPP generator is running and ready, otherwise it will be a 0.

[rshayes]

At the bottom of page 11, the data sheet says:

"If the factory default setting for the BPC (F800h) is changed, it will no
longer point to the ISP masked-ROM boot loader code. If this happens,
the only possible way to change the contents of the Boot Vector is
through the parallel programming method, provided that the end user
application does not contain a customized loader that provides for
erasing and reprogramming of the Boot Vector and Status Byte."

If the value in the BPC register is accidently changed, it appears that the serial load routine will not be started. This would prevent serial programming.

This register (BPC) does not seem to appear in the register list. The commands for reading from it or writing to it seem to be different from other register commands.

[gmclam]

I've actually written code, which under software control can vector to the factory boot loader routine. I added this code after several CPUs failed and could not be programmed in circuit. Included in my routines are the ability to read all the registers (including AUXR) and the values loaded at BPC. Since I've included this code in my application the CPUs have not failed. If/when they do, I am hoping my routine will get around this problem and effectively still allow in circuit programming.

What I am specifically wondering is if anyone has taken one of these "dead" CPUs and made them programmable in circuit again by using a parallel programmer. And if so, what specifically was programmed into the parts to make this happen.