8051 Atmel AT89S51 seems not to execute program from flash

[adinsen]

I've ventured on a journey to make a data collecting device with an 89S51 MCU - it suits my application perfectly. But the two chips I have for prototyping my application do not behave as I expect them to do as they do not seem to execute the code I'm flashing into them. Instead they start reading from external program memory triggering ALE and sending out addresses on P0 and P1.

I'm using:

• SDCC to compile my test program
• An XGecu T48 to flash the MCUs
• A simple wirewrapped prototype with the bare necessesities to interface to a 16x2 LCD and including an 11.0592MHz crystal to run the clock.
  

The code I'm flashing is probably the simplest possible test program:

Code: [Select]

#include <at89x51.h>
void main(void) {
while (1) {
P0 = 0xa5; P1 = 0x5a; P2 = 0xaa;
P0 = 0x5a; P1 = 0xa5; P2 = 0x55;
}
}
and it seems to work fine in the simulator.

I've connected a function generator to the reset pin to measure the time it takes before it starts latching addresses. It seems it takes about 300 us from the point where reset goes low until the MCU starts polling the XROM. This is so short that I don't think it even attempts to execute anything from the flash memory.

The programmer can verify the flashed code, but complains that the Atmel ID bytes are incorrect as they are FF FF FF. According to the data sheet they should be 1E 51 06. Could these be defective/counterfeit chips - or could I be missing something stupid?

[wek]

Is /EA tied high?

[EDIT] IIRC, ALE is pulsed even during internal code execution, /PSEN is the signal you are looking for.

JW

[adinsen]

Thanks! 

Is /EA tied high?

Yes

[EDIT] IIRC, ALE is pulsed even during internal code execution, /PSEN is the signal you are looking for.

You seem to be right! Here's a scope trace showing /PSEN activity (my scope isn't fast enough to show the actual pulsing in this timebase so it looks like nose...) timing now shows it takes 5ms before it starts executing. This is enough time to execute the whole of the internal flash before it enters XROM area, but P0 and P1 activity shows it's reading XRAM, there are no signs of it executing my code.

[WattsThat]

Supply bypassing? RST line have an r/c delay on it? Many years ago, I had a hand built board lock up due to ringing on the RST line at power up which caused the cpu to go off into never never land.

[PCB.Wiz]

timing now shows it takes 5ms before it starts executing. This is enough time to execute the whole of the internal flash before it enters XROM area, but P0 and P1 activity shows it's reading XRAM, there are no signs of it executing my code.

Yes, scope suggests it is simply running thru the FLASH and 'out the other end'   Blank Flash is  0xff =    MOV   R7, A
Maybe try a different code pattern and see if that pgms/verifies, and read the whole 4K and check the DisAsm of that ?

[retiredfeline]

>sending out addresses on P0 and P1

Hmm P0 outputs the low byte of the program address (and P2 the high byte) in EA mode. But you claim that /EA is tied high, so I don't know. How sure are you that you have a good MCU with a good /EA pin?

Also IIRC if the program address is > 1k, it accesses external memory no matter what the state of the /EA pin. Is it possible your program is vectoring outside flash ROM space? Interrupt vectors disabled?

[adinsen]

Supply bypassing? RST line have an r/c delay on it? Many years ago, I had a hand built board lock up due to ringing on the RST line at power up which caused the cpu to go off into never never land.

There's an axial 100nF ceramic soldered under the socket between pins 20 and 40 and 1u connected between 9 and 4. I see no signs of ringing on the scope. The function generator TTL output driving the 1u results in some rounded signals, but no overshooting or ringing. But what you say is interesting as that's what I'm seeing...

Hmm P0 outputs the low byte of the program address (and P2 the high byte) in EA mode. But you claim that /EA is tied high, so I don't know. How sure are you that you have a good MCU with a good /EA pin?

I'm pretty unsure by now... But I bought two from the same reputable vendor, and both seem ok. I'm worried that these are counterfeit chips, though as one has hard to read printing that seems to be laser engraved and not silk printed. I've tried to search for pictures of genuine 89S51's, but I haven't found any good ones. Also, the fact that thye don't have the right ID coded, but both read FF FF FF could indicate they are bad.

Yes, scope suggests it is simply running thru the FLASH and 'out the other end'   Blank Flash is  0xff =    MOV   R7, A
Maybe try a different code pattern and see if that pgms/verifies, and read the whole 4K and check the DisAsm of that ?

I've tried two different code patterns, both behave the same. But it's a good idea. I just disassembled my minimal test code read directly off the chip using D52, and there's something strange with the initialization code inserted by the SDCC ... I have to look into this... am I doing something wrong with SDCC

Code: [Select]

;
;  D52 V3.3.6 8052 Disassembly of .\AT89S51@DIP40.HEX
;  03/19/23 05:59
;
org 0
;
ljmp X0006
;
X0003: ljmp X0062
;
X0006: mov sp,#7
lcall X0077
mov a,dpl
jz X0013
ljmp X0003
;
X0013: mov r1,#0
mov a,r1
orl a,#0
jz X0035
mov r2,#0
mov dptr,#X007b
mov r0,#1
mov p2,#0
X0024: clr a
movc a,@a+dptr
movx @r0,a
inc dptr
inc r0
cjne r0,#0,X002e
inc p2
X002e: djnz r1,X0024
djnz r2,X0024
mov p2,#0ffh
X0035: clr a
mov r0,#7fh
X0038: mov @r0,a
djnz r0,X0038
mov r0,#0
mov a,r0
orl a,#0
jz X004c
mov r1,#1
mov p2,#0
clr a
X0048: movx @r1,a
inc r1
djnz r0,X0048
X004c: mov r0,#0
mov a,r0
orl a,#0
jz X005f
mov r1,#0
mov dptr,#X0001
clr a
X0059: movx @dptr,a
inc dptr
djnz r0,X0059
djnz r1,X0059
X005f: ljmp X0003
;
X0062: mov p0,#0a5h
mov p1,#5ah
mov p2,#0aah
mov p0,#5ah
mov p1,#0a5h
mov p2,#55h
sjmp X0062
;
ret
;
X0077: mov dpl,#0
ret
;
X007b: mov r7,a
;
; Miscellaneous equates
;
;  These are addresses referenced in the code but
;  which are in the middle of a multibyte instruction
;  or are addresses outside the initialized space
;
X0001 equ 1
;
end
;

EDIT: The code that confused me is just the startupcode which clears internal data memory before calling my main. SDCC manual has details on this in section 4.1.4. There are ways to avoid it from being linked in, but now that I understand what the code is doing, I'm not going to try that. Conclusion so far is that I'm using SDCC correctly, and the MCU is programmed with correct, functioning code, which it doesn't execute... 

The clock looks wierd though, see attached screenshot from the scope (this is taken with the probe at the X10 setting, so it should be legit). It's modulated with a frequency some 10 times lower than the 11 MHz clock. I have no idea where this is coming from and I did take care to fit the crystal right next to the MCU and the two 33pF capacitors also directly soldered on the back. Both XTAL pins show the same signal, only at different amplitudes. This is obviously not good so I'll try to remove the crystal and drive the MCU clock from my function generator instead... It can't do more than some 900 kHz, but that should suffice for now.

That was just my scope running too low sample rate. It looks fine at 30 MS/s.

[PCB.Wiz]

Conclusion so far is that I'm using SDCC correctly, and the MCU is programmed with correct, functioning code, which it doesn't execute... 

It does not really make sense.
You could try very, very simple ASM only code, that clears a port on the first reset 0000H, then some pin toggle code-loop,  and then at the top of flash use ORG to put one line that clears another port.
That will confirm RESET and fall-out-the-top even if nothing else works.

Do you have any other brands/variant 8051's kicking about you can drop the same code into ?

[retiredfeline]

If you decide to give up on the AT89S51s, there are lots of compatibles. I can recommend the STC89C51 or 52. Those are programmed from a serial line rather than in a programmer, but it's quite easy using stcgal.

[PCB.Wiz]

If you decide to give up on the AT89S51s, there are lots of compatibles. I can recommend the STC89C51 or 52. Those are programmed from a serial line rather than in a programmer, but it's quite easy using stcgal.

Atmel also made Serial loader parts, the AT89C51Rx series and the newer AT89LP51Rx have a ROM loader. ( IIRC that activates if PSEN is held low thru 1k during reset exit )
STC have a wide range of 8051 variants, all the way up to their STC32 parts using a MSC251 core, but some customers are avoiding Chinese sourced parts.

[adinsen]

It does not really make sense.
You could try very, very simple ASM only code, that clears a port on the first reset 0000H, then some pin toggle code-loop,  and then at the top of flash use ORG to put one line that clears another port.
That will confirm RESET and fall-out-the-top even if nothing else works.

Do you have any other brands/variant 8051's kicking about you can drop the same code into ?

The code is strange indeed, but is described to set the stackpoint and clear the XRAM and IRAM, which makes sense for a C-runtime where variables are expected to be initialized to 0. I think the code was probably written in C then comiled, and may attempt to do a number of things at the same time. The initialization code can be easily bypassed, though, which I've attempted, so it's not running - result is the same. I don't have any other 8051's in my drawers, unfortunately. I'll try a pure ASM version this evening, just to be sure.

If you decide to give up on the AT89S51s, there are lots of compatibles. I can recommend the STC89C51 or 52. Those are programmed from a serial line rather than in a programmer, but it's quite easy using stcgal.

The AT89S51 is also serial programmable, which I need in my application. I just can't find my Arduino so that I can reprogram my USBASP https://ilyal.eu/usbasp-v-2-0-firmware-for-flashing-at89s51-at89s52. I'll probably go for an ATMEGA16-16PU if I give up. I need all the I/O pins, but my code will be simple, so the 4K flash and 128 bytes RAM of the 89S51 are plenty enough - and I'm a bit nostalgic about the old 8051 architecture

Atmel also made Serial loader parts, the AT89C51Rx series and the newer AT89LP51Rx have a ROM loader. ( IIRC that activates if PSEN is held low thru 1k during reset exit )
STC have a wide range of 8051 variants, all the way up to their STC32 parts using a MSC251 core, but some customers are avoiding Chinese sourced parts.

The AT89C51 is AFAIK the older version which cannot be serially programmed? My chips have hard-to-read "TAIWAN" printed on the bottom, by the way.

[PCB.Wiz]

Atmel also made Serial loader parts, the AT89C51Rx series and the newer AT89LP51Rx have a ROM loader. ( IIRC that activates if PSEN is held low thru 1k during reset exit )
STC have a wide range of 8051 variants, all the way up to their STC32 parts using a MSC251 core, but some customers are avoiding Chinese sourced parts.

The AT89C51 is AFAIK the older version which cannot be serially programmed? My chips have hard-to-read "TAIWAN" printed on the bottom, by the way.

Yes, the AT89C51 / AT89C52 are very old, and lack any serial pgm  - the newer FX core parts like AT89C51RB/RC/RD and new 1T AT89LP51RB/RC/RD/ID all have UART serial boot ROM included.


The SPI serial pgm parts started with AT89S2051/ AT89S4051 / AT89S51 / AT89S52  etc and the new 1T AT89LP51 / AT89LP52 / AT89LP4052  are all no-boot-rom simpler versions.
The AT89LP51RB/RC/RD/ID/ED have both SPI and Serial boot options.

You can SPI ISP those AT89S51/52/LP51/LP52, as you mention, so that may be 'good enough' for your needs ?

At the basic end, the newer AT89LP52 is cheaper than AT89S52 at Digikey, and has a wider supply range, and is faster.

[retiredfeline]

Nah, the C runtime initialisation code is fine. I use SDCC with the STC89 8051 clones without any special considerations. That startup code hand crafted by the way, and you can find the source in crtstart.asm in the source distribution.

[adinsen]

Is it ok to share frustration at this forum - i hope so 

I have hand crafted the following machine code - it doesn't execute:

Code: [Select]

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).

(I know the code is located across the interrupt vectors, but a working 8051 should have no interrupts after reset until they're enabled per port/timer/uart.)

Is it my XGecu programmer? Is it the chips? Is it me who has a bad karma? I'm getting that - my wife is starting to complain!

Its funny, though, that two black plastic things with metal pins on the side can cause so much brain activity...  I'm going to stop now and take a new route. The vendor that sold me the 89S51's came back and reflected that they haven't had complaints with the batches before and could I test with a known good programmer and in a known good circuit? Good suggestions, but I don't have that. The mystery will be solved, but not yet... I have a project i WANT to complete. ATMEGA16 or AT89LP52 both seem great options. Price is not really an issue, 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 (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? ).

I'll be away the coming days, so don't expect any progress. But I'm thankful for all the help you guys have given!! 

/Anders

[PCB.Wiz]

I have hand crafted the following machine code - it doesn't execute:

Code: [Select]

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.

[adinsen]

Great news! I figured out I could connect the T48 to ICE programming interface. I don't know why I didn't realize that was even possible with the T48 without an adapter

The programmer now recognizes the correct chip ID of the 89S51 and my test code (including the SDCC runtime) executes perfectly. The screenshot below shows P0 and P2 outputs (P0 has 10k pullups connected trough ~6 cm wire wrap wires).

Conclusion so far, don't use parallel programming with the XGecu programmer 

Problem solved!!!!  

EDIT: It turns out the chips are really 89S52 chips id'd as 89S51 and that the parallel programmer reads the same code as serial when I configure it as 89S52... 

[PCB.Wiz]

Problem solved!!!!  

Great it is now working   

Maybe serial is what they tested ? - The really strange part is that parallel pgm verify worked ?

EDIT: It turns out the chips are really 89S52 chips id'd as 89S51 and that the parallel programmer reads the same code as serial when I configure it as 89S52... 

You mean you can Serially pgm and then read back OK parallel, if you select AT89S52 ? 
Did you try program above 4K ? I know they use the same die, but I think they fuse set the size.

What does the parallel programmer read back if you select AT89S51 - ie where does it place your code.
If you read back a part parallel programmed, via serial, where does the code show up ?
 

[adinsen]

You mean you can Serially pgm and then read back OK parallel, if you select AT89S52 ? 
Did you try program above 4K ? I know they use the same die, but I think they fuse set the size.

What does the parallel programmer read back if you select AT89S51 - ie where does it place your code.
If you read back a part parallel programmed, via serial, where does the code show up ?

I can serially program and read back in parallel selecting AT89S52 and I can program the upper 4K in parallel mode ignoring the ID. The serially programmed code programmed as AT89S51 ends up in the lower 4K of the chip when reading it back as an AT89S52. I suspect parallel programming it as an AT89S51 and reading back as AT89S52 will show that the code ends up in the upper 4K.

The T48 programmer probably just leaves P2.4/parallel A12 unconnected in AT89S51 mode. There's no mention of P2.4 in the AT89S51 data sheet about parallel programming, so that should be fine, but the internal pullups will then make it a 1. Perhaps Atmel did not fuse set the size on this batch in the same way they normally do and as you suggest tested them in a way so the defect didn't show up.

[PCB.Wiz]

You mean you can Serially pgm and then read back OK parallel, if you select AT89S52 ? 
Did you try program above 4K ? I know they use the same die, but I think they fuse set the size.

What does the parallel programmer read back if you select AT89S51 - ie where does it place your code.
If you read back a part parallel programmed, via serial, where does the code show up ?

I can serially program and read back in parallel selecting AT89S52 and I can program the upper 4K in parallel mode ignoring the ID. The serially programmed code programmed as AT89S51 ends up in the lower 4K of the chip when reading it back as an AT89S52. I suspect parallel programming it as an AT89S51 and reading back as AT89S52 will show that the code ends up in the upper 4K.

The T48 programmer probably just leaves P2.4/parallel A12 unconnected in AT89S51 mode. There's no mention of P2.4 in the AT89S51 data sheet about parallel programming, so that should be fine, but the internal pullups will then make it a 1. Perhaps Atmel did not fuse set the size on this batch in the same way they normally do and as you suggest tested them in a way so the defect didn't show up.

Ah, that all makes sense.
Atmel likely fuse just CODE FETCH to 4k on 89S51, but leave the full 8k flash program, side unchanged. That means the top 4k is still there, but not seen by code, which jumps external at 4096
Thus the 4k part programs and verifies but fails to run. 

The programmer vendor will not have run actual code, they just confirm erase/pgm/verify (which all 'works).  You could feed back a bug report to the T48 programmer software team ?

These days, the 8k parts are the same price as the 4k parts, so the 4k parts are fading anyway. (and newer LP52 are cheaper than older S52)

[adinsen]

Ah, that all makes sense.
Atmel likely fuse just CODE FETCH to 4k on 89S51, but leave the full 8k flash program, side unchanged. That means the top 4k is still there, but not seen by code, which jumps external at 4096
Thus the 4k part programs and verifies but fails to run. 

The programmer vendor will not have run actual code, they just confirm erase/pgm/verify (which all 'works).  You could feed back a bug report to the T48 programmer software team ?

These days, the 8k parts are the same price as the 4k parts, so the 4k parts are fading anyway. (and newer LP52 are cheaper than older S52)

Yeah, it could be a good idea to feed them a bug report, OTOH this is likely an incorrectly configured (fused) batch which just slipped through production verification. According to the data sheet, in parallel programming, only address lines 0-11 should be connected. See the snip below.

So here's what I think happens: The chips are fused wrongly for parallel programming and it's possible to access all of the 8K on the die. So there's actually also an A12 on P2.4. The internal pullup on that port, however, sets it to 1...

I'll need a lot of different 82S51's to find out for sure ...