I have hand crafted the following machine code - it doesn't execute:
org 0
;
X0000: mov p0,#0a5h ; 0000 75 80 a5 u.%
mov p1,#5ah ; 0003 75 90 5a u.Z
mov p2,#0aah ; 0006 75 a0 aa u *
mov p0,#5ah ; 0009 75 80 5a u.Z
mov p1,#0a5h ; 000c 75 90 a5 u.%
mov p2,#55h ; 000f 75 a0 55 u U
ajmp X0000 ; 0012 01 00 ..
It actually executes differently on a breadboard clock at 120 kHz driving by my function generator than in my prototype with the 11 MHz crystal. Both start executing XCODE, but on the breadboard it only does a little. On the prototype, it reliably (?) executed all of XCODE, and none of flash (this is visible looking at A15 which has a 44% duty cycle indicating that it starts executing at 0x1000 or just executes a very few instructions from internal flash).
Not quite, I make ~44% exactly what you would expect from a simple wrap around, with 4K of Flash internally.
If the CODE fetch is a stable opcode (like 0x00 or 0xff) you will just wrap continually like a blank device, but floating pins will not give 0x00 or 0xff, so pullups or pulldowns are needed.
(32768-4096)/65536 = 43.75%
Is it my XGecu programmer? Is it the chips?
It's strange, if you can read back the flash.
Address patterns of expected kHz mean the OSC is active and chip is trying to read
something, but symptoms suggest internal code is simply blank to the CPU.
If Address lines cease on RST, it means the chip is seeing the RST.
You could try two different code patterns, and pgm Chip 1 = A Chip 2 = B and then read back Chip 1, so you know the code must be arriving from chip read and not a buffer ghost.
I've created rolling pattern HEX files with assembler that XOR Upper address with lower address, which means all pages differ, good for programmer checking.
but I'm somewhat in love with the idea of low power consumption and not having to fit a crystal and still be able to use the UART - which the AT89LP52 promises. OTOH, the ATMEGA16 has a fully vendor supported toolchan
Does it have to be DIP40 ? SiLabs have some modern C51's in their EFM8BB5x series, run to 50MHz, but not in DIP40
Addit: if it
needs to be DIP40, and have a CalOsc, looking at LCSC and sorting by price/stock and ignoring the 'quite old' parts, finds
( The STC parts all have serial bootloaders)
STC32G12K128-Beta-PDIP40 154 In Stock 10+ US$1.233 128k flash 12K ram USB and it would be a fun part to play with. 8051 core, with 'extras'
STC8H8K64U-45I-PDIP40 59 In Stock 10+ US$1.3603 I think same pinout as above
STC15F2K60S2-28I-PDIP40 204 In Stock 10+ US$1.4876 60K flash 2K RAM
STC12C5A60S2-35I-PDIP40 978 In Stock 10+ US$1.5114 << standard / old 8051 DIP40 pinout.
ATMEGA16A-PU 853 In Stock 10+ US$3.6385 16k Flash
ATMEGA4809-PF 31 In Stock 10+ US$4.8794
PIC16F19176-I/P 112 In Stock 10+ US$4.8285
and Digikey shows
PIC18F45Q10-I/P IC MCU 8BIT 32KB FLASH 40DIP Microchip Technology 191 In Stock 1,000 : $2.03500
AT89LP52-20PU IC MCU 8BIT 8KB FLASH 40DIP Microchip Technology 453 In Stock 1,000 : $2.75000
(and I still think the SDCC startup code is strange, e.g. why on earth is it doing stuff on port 2, is it trying to find some XRAM or XCODE without using the CPU for it?
).
P2 is used along with MOVX @Ri,A for paged XDATA access, and can avoid DPTR if that is used for MOVC for example.