Electronics > Microcontrollers

8051 Atmel AT89S51 seems not to execute program from flash

(1/4) > >>

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: ---#include <at89x51.h>
void main(void) {
while (1) {
P0 = 0xa5; P1 = 0x5a; P2 = 0xaa;
P0 = 0x5a; P1 = 0xa5; P2 = 0x55;
}
}
--- End code ---

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.[attach=1]

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!  :)


--- Quote from: wek on March 18, 2023, 12:13:10 pm ---Is /EA tied high?

--- End quote ---

Yes


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

--- End quote ---

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:

--- Quote from: adinsen on March 18, 2023, 12:50:46 pm ---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.

--- End quote ---

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 ?

Navigation

[0] Message Index

[#] Next page