Dear all, I have a working program which has been running for about a year. This project uses the AT89C51ED2 from Atmel. Seeing as I was using uV Version 7.02 which didn't support this chip I decided to upgrade and am now running V7.50a (I believe the latest). I did some alterations on the above mentioned project like changing timers and including the origional keil header file instead of the one I altered myself, and then recompiled. Tested the project in the simulator, everything seems ok. Then I flashed a chip and.... nothing.... Even the Outputs didn't get set to "0". After examining the header files I came accross the following differences. Old altered file: sbit P1_7 = P1^7; sbit P1_6 = P1^6; sbit P1_5 = P1^5; New AT89C51XD2.h file Sbit (P1_7 , 0x90, 7); Sbit (P1_6 , 0x90, 6); Sbit (P1_5 , 0x90, 5); etc...etc...etc... In my progarm I have the following: sbit relais = P1^1; sbit active = P1^0; etc...etc... The question: Could this be the cause of the problem? If so, why don't I get compiler errors? Thanks in advance for any responses. Regards John Garrelts
Thanks for your reply Erik, I understand that the address of P0^0 = 0x90 bit 0. I'm just trying to understand why a previously running program stopped running. The only main thing I changed since ungrading was the header files. Regards John
Well, the new header looks like it has a preprocessor Macro to avoid directly using Keil's proprietary language extensions. This is generally a Good Thing. You need to check the preprocessor listing to make sure that it's actually expanding correctly...
I understand that the address of P0^0 = 0x90 bit 0. I'm just trying to understand why a previously running program stopped running. The only main thing I changed since ungrading was the header files. My guess is a mistype like the one above (P0^0 = 0x90 bit 0). NOTE, the mistype could be in your original header file. One of the meanest bugs I have been exposed to was modifying a project where the original coder (this could not have been a programmer) had "fixed" errors by e.g. when he found out that what he had coded a being attached to p1.5 really was at p0.3 he changed the definition of p1.5 to 0x83. When I say "the mistype could be in your original header file" I am not trying to insult you, but mistakes DO happen. Erik
No offence taken Erik, glad for some help. I have written a simple trial program, can't get much simpler than this. and this also doesn't run.
#include <REG51xD2.h> #include <stdio.h> sbit IObit_0 = P1^0; sbit IObit_1 = P1^1; void main(void) { IObit_0 = 0; IObit_1 = 0; while(1) { } }
; FUNCTION main (BEGIN) ; SOURCE LINE # 15 ; SOURCE LINE # 16 ; SOURCE LINE # 17 0000 C290 CLR IObit_0 ; SOURCE LINE # 18 0002 C291 CLR IObit_1 0004 ?C0001: ; SOURCE LINE # 20 ; SOURCE LINE # 21 ; SOURCE LINE # 22 0004 80FE SJMP ?C0001 ; FUNCTION main (END) C51 COMPILER V7.50 REC_UNIT_LEDBLINK 02/02/2005 10:53:46 PAGE 8 NAME CLASS MSPACE TYPE OFFSET SIZE ==== ===== ====== ==== ====== ==== P1 . . . . . . . . . . . . . . . . . . SFR DATA U_CHAR 0090H 1 size_t . . . . . . . . . . . . . . . . TYPEDEF ----- U_INT ----- 2 main . . . . . . . . . . . . . . . . . PUBLIC CODE PROC 0000H ----- IObit_0. . . . . . . . . . . . . . . . ABSBIT ----- BIT 0090H 1 IObit_1. . . . . . . . . . . . . . . . ABSBIT ----- BIT 0091H 1
I forgot to mention. The header file above is the origional keil version without any edits made Regards John
Have you tried burning the original working hex file into the chip?
I think I've found the problem. It seems like I've got a bad datch of Micro's. 1 out of 5 work..... Thanks for the back-up everyone Regards John
If anything is new it should be tested on hardware that was tested wiyh the old. So often a hardware bug will show up as a software bug and vv. Erik
Sorry if I wasted your time Erik, It wasn't intentional. I did test the program on a tested (working) hardware setup. The only physical difference was a different micro. Same type, serial number, for the rest everything the same. Just the latest batch of micro's don't seem to work. What made me think of the Keil software was that was what I updated last. My mistake... sorry everyone Hope no one's to mad at me..... Regards John Garrelts
If I were to be mad at you, I would have been mad at myself for similar reasons who knows how many times. We all think we follow good practice (In yourcase reprogram the same micro) and often find that we do not. Erik
Which programmer do you use?
I use a HiLo ALL-11 P2... It programmes the flash ok, just the I/O of the micro's aren't functioning Regards John
hi, I've got a bad datch of Micro's. 1 out of 5 work I doubt that Atmel does its work so bad. I have using alot of AT89C51ED2 and there were no bad chips. Do you read its Errata: http://www.atmel.com/dyn/resources/prod_documents/doc4257.pdf - maybe the problem is there. Regards, Oleg
Do you read its Errata: - maybe the problem is there. Maybe, maybe not. I refuse to use Atmel because of something that happened when an error did not appear in the errata till more than a year after I reported it. Erik