8051Debugging Help needed ( LED not blinking :P) - Page 1
Forum section: electronics / beginners

author: rohan-04
author_rank: Contributor
timestamp: August 11, 2013, 10:14:31 am
content: So about two weeks ago I decided on starting a new project, this comes with using an AT89C2051 as the uC. I'm using the willar USB programmer and absolutely nothing. I've checked the circuit a few times and also changed every component. Below is a schematic and picture of the circuit.Code:#include<reg51.h>// LED Pinsbit LED = P1^0;// Pin P1.0 is named as LED//Function declarationsvoid cct_init(void);void delay(int a);int main(void){cct_init();// Make all ports zerowhile(1){LED = 0;// Pin P1.0 Lowdelay(30000);// Half sec delayLED = 1;// Pin P1.0 Highdelay(30000);// Half sec delay}}void cct_init(void){P0 = 0x00;P1 = 0x00;P2 = 0x00;P3 = 0x00;}void delay(int a){int i;for(i=0;i<a;i++); //null statement}I dont think I've wired up the reset correctly, I've got the 10uf cap going form 5v to a 10K res which goes to GND. Also I have some serious doubts on my programmer Willar 200s its an open source usb programmer that is widely available here in Bangalore India.Edit 1: Dont know if this will change anything but I'm running the system of a 12V-2A wall adapter that is reduced via a LM7805 with a 0.1uf and a 1000uf.

author: Psi
author_rank: Super Contributor
timestamp: August 11, 2013, 10:18:10 am
content: I can see one major problem that will stop it from working.Check the mcu pin numbering, it isn't the way you have that wired up.With 99.9% of DIP/SOIC chips (this one included) the last pin (20 in this case) is located right above pin 1.You have the led connected to pin 19 instead of 12, also you have power going into pin 11 instead of pin 20The chip should be ok. Wiring it up that way wont have damaged it.

author: rohan-04
author_rank: Contributor
timestamp: August 11, 2013, 10:28:00 am
content: You're right. But this was an error i made in breadboarding quick so i could get this post up. I've corrected it and uploaded a new pic still no different.

author: Psi
author_rank: Super Contributor
timestamp: August 11, 2013, 10:38:51 am
content: I have no experience with the 8051 but from the datasheet it seems pretty clear that RESET is active high instead of active low like most mcus.If this is the case then holding it high, like you are doing with a pullup, will keep the mcu in a reset state instead of a run state.Try moving the reset resistor so its a pulldown instead of a pullup. It may not reprogram like that but it might start running your code (if it has been programmed successfully in the past).EDIT:i just noticed that you have it correct in the circuit diagram. Its just another breadboard issue.

author: PA0PBZ
author_rank: Super Contributor
timestamp: August 11, 2013, 11:15:38 am
content: The caps on the Xtal are taking the long route now, you better connect them directly to pin 10.Also, put a decoupling cap between pins 10 and 20.

author: Psi
author_rank: Super Contributor
timestamp: August 11, 2013, 11:21:26 am
content: Also, if you have a scope, check if the xtal is oscillating (x10 probe)

author: rohan-04
author_rank: Contributor
timestamp: August 11, 2013, 11:34:06 am
content: Unfortunately, I cant afford and scope nor do i know enough of what im doing to be safe with one. I will try changing rest around and added the caps.

author: rohan-04
author_rank: Contributor
timestamp: August 11, 2013, 11:36:50 am
content: Quote from: PA0PBZ on August 11, 2013, 11:15:38 amWhat do you mean long route? And Is it not necessary for the caps to be connected to the crystal? Added the caps on 10 and 20 and didnt get anything.

author: RoadRunner
author_rank: Frequent Contributor
timestamp: August 11, 2013, 12:01:33 pm
content: i guess atmel 8051 mcu is not capable of sourcing much current from the port pin , even not enough for a tiny led.but port pin can sink 20mA so connect your led backwards i hope it can work.

author: c4757p
author_rank: Super Contributor
timestamp: August 11, 2013, 12:05:51 pm
content: Yep.They're only meant for high-current sink, not source. Flip the LED around.

author: Psi
author_rank: Super Contributor
timestamp: August 11, 2013, 12:06:19 pm
content: Yeah, move the led+resistor so its between P1.0 and VCCQuote from: rohan-04 on August 11, 2013, 11:36:50 amHe means the GND for the xtal caps has to travel longer than it needs to. When it comes to xtals, keep the connections short.I don't think that's your problem though.

author: amyk
author_rank: Super Contributor
timestamp: August 11, 2013, 12:21:13 pm
content: Quote from: c4757p on August 11, 2013, 12:05:51 pmAccording to the datasheet it can only source ~80uA to maintain a voltage of 2.4V.I've always wondered why this is the case - for NMOS I can understand the pullup resistor creates a source impedance, but wouldn't it be symmetrical for CMOS?

author: Psi
author_rank: Super Contributor
timestamp: August 11, 2013, 12:25:36 pm
content: The high side transistor in the driver is probably being using for a dual purpose to save on transistors.If it pulls high through a resistor then it can both..- Enable/disable a pullup for inputs- Pull high for an output (but due to the resistor quite weakly)At least, that's my guess.

author: free_electron
author_rank: Super Contributor
timestamp: August 11, 2013, 01:21:48 pm
content: That port on an 8051 is pull down only. The 80ua is a small current source to dampen glitches.

author: rohan-04
author_rank: Contributor
timestamp: August 11, 2013, 05:28:04 pm
content: Quote from: Psi on August 11, 2013, 12:06:19 pmHow would one do this?From what I understand P1 isnt supplying enough current to the led. I connected the led directly and the res to the - side still nothing.

author: free_electron
author_rank: Super Contributor
timestamp: August 11, 2013, 07:41:16 pm
content: 5 votls - led anode - led cathode - resistor - resistor pin of 8051

author: rohan-04
author_rank: Contributor
timestamp: August 11, 2013, 08:21:50 pm
content: Still nothing. I also tried a different Port and changed the code for P3.0 and still nothing. The led is just brighter now also changed the res from 10k to 1.8k.

author: Psi
author_rank: Super Contributor
timestamp: August 12, 2013, 06:35:39 am
content: Quote from: rohan-04 on August 11, 2013, 05:28:04 pmThe output pins on that mcu are like switches to GND. That's all they can really do. It can't output a voltage like a modern micro can. (at least not at any usable current).Connect it like this, (make sure you get the led around the right way)This way, when the code outputs a "low", the output will switch GND onto the resistor and the led will light up.When the code outputs a "high" the led will switch off.

author: qno
author_rank: Frequent Contributor
timestamp: August 12, 2013, 06:39:56 am
content: This reminds me of:Das machine is nicht fur gefingerpoken und mittengrabben. Ist easyschnappen der springenwerk, blowenfusen und corkenpoppen mitspitzensparken. Ist nicht fur gewerken by das dummkopfen. Dasrubbernecken sightseeren keepen hands in das pockets. Relaxen undvatch das blinkenlights!!!

author: Psi
author_rank: Super Contributor
timestamp: August 12, 2013, 06:43:06 am
content: This microcontroller is so old it probably has a grey beard made of tin whiskers.

author: lapm
author_rank: Frequent Contributor
timestamp: August 12, 2013, 07:17:24 am
content: Well heres few things i have learned over the years with microcontrollers.- Crystal oscillator, make sure you have proper bypass capacitor to ground. Keep ground path short as bossible.- Pin out of chip, check it, check it again just in case.- Output pins, check datasheet for internal hardware to see what its exactly can do. PIF16F84 had infamous RB4 pin that could not source current at all, could sink it well... Bite me first time i tried to use it... Yes this is old example but very fitting when if comes to pin thats open-drain type output only.- Options inside program code that can effect how chip behaves, oscillator settings, etc... Make sure you know the default values witch chip comes from factory.- Always double check your connections. Not a few times i have forgot one wire from breadboard and that missing wire has caused circuit to do strange things...- Program code itself, are you sure you understand what its doing or is supposed to be doing. I have tons of these, bugs, incompability issues between chips over missing hardware options, etc...- If anything else fails, go back to basics, read datasheet again, bring out multimeter and just try drive that pin up or down...Yes, even after all these years i still get bit by some of these still. Live and learn i say. Failure often teaches us more then success.

author: rohan-04
author_rank: Contributor
timestamp: August 12, 2013, 01:00:48 pm
content: Still nothing gentlemen, I've done the re-arrangement of the led and res. This all just points to the programmer being at fault, or could there be an issue with the header file?

author: JoeO
author_rank: Frequent Contributor
timestamp: August 12, 2013, 03:09:41 pm
content: Divide and conquer: Write a program to turn on the LED and then endless loop. Then write a program to turn the LED off and endless loop. These results will tell you where your problem is.

author: Alana
author_rank: Frequent Contributor
timestamp: August 12, 2013, 06:14:20 pm
content: Quirks about 8051 family in 20pin packages - port p1.0 and p1.1 is kind of open collector - those 2 pins are connected to internal analouge comparator and cannot source current. This should not be an issue here but you may try to move to some other pins.And if you are unsure about your programing try to test your circut using Bascom 8051 or even assembly language. At least for me those two are easier than C for 8051 family.

author: Psi
author_rank: Super Contributor
timestamp: August 12, 2013, 11:18:12 pm
content: I'm beginning to think the chip hasn't been programmed.

author: sync
author_rank: Frequent Contributor
timestamp: August 12, 2013, 11:31:46 pm
content: Quote from: rohan-04 on August 11, 2013, 10:14:31 amIs that a working delay() function?It has no result. The compiler is free to replace it with nothing.

author: rohan-04
author_rank: Contributor
timestamp: August 12, 2013, 11:39:36 pm
content: Quote from: Alana on August 12, 2013, 06:14:20 pmTried it on P3 and same issue.

author: Psi
author_rank: Super Contributor
timestamp: August 13, 2013, 12:38:26 am
content: I doubt the issue is the delay function, even if the compiler optimized it out you'd see some light from the LED, it would just be less bright. Maybe ~30% due to pwm.

author: bbarbour
author_rank: Contributor
timestamp: August 13, 2013, 12:51:54 am
content: I'm with Psi. It's likely that the uC isn't actually programmed. If you've triple checked everything with the circuit and modified the program to simply turn on the LED (as suggested above, set the pin low, not high, and connect the cathode of the LED to the pin and the anode to an appropriate voltage source), then it's likely that the controller isn't doing anything. Unfortunately it can be challenging to confirm whether or not something is programmed successfully or not (depending on the programmer). One thing you could do is set a pin to oscillate (blink) and use a multimeter to determine which pin is exhibiting the behavior you programmed. That way you can remove the diode from the mix (just in case the LED is dead or something).

author: c4757p
author_rank: Super Contributor
timestamp: August 13, 2013, 01:00:52 am
content: I agree. Not programmed.Easiest "is it programmed" check IMHO is to program it with a simple infinite loop toggling a pin. Don't even bother with timing, you don't want to check if that's right too, you just want the pin to toggle. Add a pullup if required and toss a scope probe at it. Even better, toggleallthe pins.

author: JoeO
author_rank: Frequent Contributor
timestamp: August 13, 2013, 02:08:33 am
content: Quote from: c4757p on August 13, 2013, 01:00:52 amHe doesn't have a scope.

author: c4757p
author_rank: Super Contributor
timestamp: August 13, 2013, 02:34:58 am
content: Oops. Looks like I sold my reading comprehension to pay for my scope.Scopeless upgrade: program it once to set all pins low, then program it again to set all pins high.

author: rohan-04
author_rank: Contributor
timestamp: August 13, 2013, 09:06:33 am
content: I dont know if this is any good but the programmer I have has this "read" function (attached), it also has a "blank check" function that gives the appropriate messages when applied.

author: PA0PBZ
author_rank: Super Contributor
timestamp: August 13, 2013, 09:23:04 am
content: Well, that's empty for sure, I guess the blank check tells you that it is.

author: amyk
author_rank: Super Contributor
timestamp: August 13, 2013, 12:08:34 pm
content: Not exactly, that contains LJMP 082F followed by a ton of MOV R7, A.Now go look at 82F and see if that's also all FFs or if there's something there.

author: PA0PBZ
author_rank: Super Contributor
timestamp: August 13, 2013, 12:22:26 pm
content: Quote from: amyk on August 13, 2013, 12:08:34 pmOops.... Next time coffee first, then postBut wait:'The AT89C2051 is a low-voltage, high-performance CMOS 8-bit microcomputer with 2K bytes of Flash programmable and erasable read-only memory (PEROM).'.2K, isn't that from 0000-07FF?

author: rohan-04
author_rank: Contributor
timestamp: August 18, 2013, 02:07:29 pm
content: So after changing the code to suite the numerous debugging tests. I've found what seems to be problem. The desktop program "Willar Programmer" has issues with the hex files thats loaded, the error I get is "Warning: Some data out of range has been ignored", but when I load a different hex file no such error and when I read the uC using the software it displays appropriately. So I'm guessing this is the problem.Attached : Screenshot of the error.

author: PA0PBZ
author_rank: Super Contributor
timestamp: August 18, 2013, 05:17:29 pm
content: As you can see in my last message the code starts with a jump to 082F, but your processor only has 2KB program memory (0000-07FF). That is probably also why you get this warning: in the HEX file is code that can not be programmed in the processor. Have a good look at the program (compiler?) where you generate this code, I'm sure that there is a setting wrong, like the wrong target processor or something like that.

author: rohan-04
author_rank: Contributor
timestamp: August 18, 2013, 06:05:53 pm
content: using uVision4. Right I'm inspecting it now. I dont see whats wrong honestly.

author: PA0PBZ
author_rank: Super Contributor
timestamp: August 18, 2013, 07:05:36 pm
content: The only thing I see is the missing 'v' at the "use On-chip ROM". That could make the difference.

author: tinhead
author_rank: Super Contributor
timestamp: August 18, 2013, 07:13:48 pm
content: it could, but here µV should not care about when C2051 selected.What i didn't really got, why you loading two hex files into programmer?

author: PA0PBZ
author_rank: Super Contributor
timestamp: August 18, 2013, 07:18:39 pm
content: Quote from: tinhead on August 18, 2013, 07:13:48 pmI think the second one was a test to see if it would load without a problem (Still don't want to know what it does)If it fails again can you attach the uc.hex file for inspection?

author: rohan-04
author_rank: Contributor
timestamp: August 18, 2013, 07:30:14 pm
content: Exactly. The second hex is the reason I'm learning the 8051, its for a speedometer for a bikeSo yeah I built a new project with the correct settings and still a no go.Quote from: PA0PBZ on August 18, 2013, 07:05:36 pmCode:MODULE: Code.obj (CODE)*** ERROR L120: CONTENT BELONGS TO ERRONEOUS SEGMENTSEGMENT: ?PR?_DELAY?CODEMODULE: Code.obj (CODE)Program Size: data=9.0 xdata=0 code=69Target not createdI get this error on selecting it.P.S - Its now called At89c20

author: tinhead
author_rank: Super Contributor
timestamp: August 18, 2013, 07:48:45 pm
content: no idea what you doing, when i create new project, select AT89C2051, create new C file, paste your code and compile/debug the virtual port is blinking. Zip your new project and attach/post here, maybe it is your µV version doing something ugly.

author: rohan-04
author_rank: Contributor
timestamp: August 18, 2013, 09:51:42 pm
content: I guess thats the case. Should I try it with SDCC and eclipse?

author: tinhead
author_rank: Super Contributor
timestamp: August 18, 2013, 10:33:45 pm
content: don't give up that fastThe linker is creating in your version a gap:Code:* * * * * * * D A T A M E M O R Y * * * * * * *REG 0000H 0008H ABSOLUTE "REG BANK 0"IDATA 0008H 0001H UNIT ?STACK* * * * * * * C O D E M E M O R Y * * * * * * *CODE 0000H 0003H ABSOLUTE0003H 07FDH *** GAP ***CODE 0800H 0018H INBLOCK ?PR?_DELAY?CODECODE 0818H 0014H INBLOCK ?PR?MAIN?CODECODE 082CH 000CH UNIT ?C_C51STARTUPCODE 0838H 000AH INBLOCK ?PR?CCT_INIT?CODEas you working with code limited Keil version it might be an general test version issue or simply the version you have is somehow broken. I would say download the latest (9.52) and try to recompile your code. When i compile with my version (9.52 non limited), your unchanged project works as supposed to do (attached hex, so you can watch blinking LED waiting for the Keil download ready)

author: rohan-04
author_rank: Contributor
timestamp: August 18, 2013, 10:39:20 pm
content: Yup. Its too late for me to start breadboard and see what happens but I have successfully got the application to program the uC.Now lets see what happens with the latest issue.

author: rohan-04
author_rank: Contributor
timestamp: August 19, 2013, 01:27:05 pm
content: Ok so while the uC accepts the hex file you gave and transfers to the controller properly, however the led still did not blink. On the other hand the new version 9.52 is still no different, same error of the data being out of range. So all we've manage to solve as of now is the fact that the programmer application and keil on my computer arent working. Could it be an OS issue? I'm using windows 8

author: lapm
author_rank: Frequent Contributor
timestamp: August 19, 2013, 08:12:45 pm
content: Sounds more like some sort of compiler issue. Especially since you get that out of range error.Make sure what size of hex file compiler allows you to do, some of them allows quite small on free licences.Might also be worth take a look at header files compiler try's to use for chip you are using. Would not be first time header files or definition files have errors them.Then next step would probably be to identify why compiler generates too large block of code space. Blinking led should be just few commands even if you do crude delay on it. => small hex file.

author: tinhead
author_rank: Super Contributor
timestamp: August 20, 2013, 01:22:43 pm
content: the same compiler/µV version, but licensed, is working properly. The only diff is the extra gap space, so for me it looks like a bug in linker.EDIT: a bit unfair to let beginner to fight with compiler ^^ So i installed trial version and it does not work as well. That means that the trial license is breaking the code (adding the gap while linking).

author: rohan-04
author_rank: Contributor
timestamp: August 20, 2013, 04:05:52 pm
content: Quote from: tinhead on August 20, 2013, 01:22:43 pmhaha yeah I had no clue what I was doing there. Anyway so now that we've gotten this aspect sorted, I'd require a favor from someone on the forums. The reason for the hex error was the compiler but the reason for the led not blinking was the .h file apparently keil has a specific 2051.h file, so i guess thats why the led didnt blink when I used the hex complied by you? back to the favor I'm made the necessary changes to the project can you compile another hex for me?P.S- Im stuck for the hex. eclipse and sdccc arent allowing me to create packages some java nullpoiint error

author: tinhead
author_rank: Super Contributor
timestamp: August 20, 2013, 04:46:03 pm
content: sure, see attached.Quote from: rohan-04 on August 20, 2013, 04:05:52 pmhehe, if there is something i really hate then eclipse and/or java crap.

author: PA0PBZ
author_rank: Super Contributor
timestamp: August 20, 2013, 04:57:38 pm
content: Quote from: rohan-04 on August 20, 2013, 04:05:52 pmThe .h file is only needed during compile time, the resulting hex file is a standalone program so that can not be the reason the hex file is not working/ the led is not blinking.

author: rohan-04
author_rank: Contributor
timestamp: August 20, 2013, 04:59:55 pm
content: Oh damn it. So the error is still the compiler?

author: PA0PBZ
author_rank: Super Contributor
timestamp: August 20, 2013, 05:26:26 pm
content: Quote from: rohan-04 on August 20, 2013, 04:59:55 pmI don't think so, tinhead sent you a working (at least it seems to work in simulation) hex file and you were not able to make it work on your chip, so there must be something else wrong. Maybe there is a different led configured in the file that tinhead sent you? Maybe your programmer is unable to program the chip correctly? Maybe your chip is broken? I don't know really...I'm almost at the point that I'm going to download the trial Keil version to see what it does here

author: tinhead
author_rank: Super Contributor
timestamp: August 20, 2013, 05:35:00 pm
content: Quote from: PA0PBZ on August 20, 2013, 05:26:26 pmwell i did it, and as said above, the trail version have an issue with linker.I've opened already case at arm.com, we will see what they will answer.rohan-04, in the meantime you can use different compiler.The hex i've attached, when i run it in debugger it works - see virtual port

author: rohan-04
author_rank: Contributor
timestamp: August 20, 2013, 06:20:32 pm
content: With the compiled hex my programmer is acting up so, Ill get back to you guys. Thanks alot for the effort!

author: tinhead
author_rank: Super Contributor
timestamp: August 21, 2013, 10:01:41 am
content: here we go, i got answer from Keil.Dear,this is one of the limitations of an evaluation version. Please see our limits:http://www.keil.com/demo/limits.aspC51 Evaluation Tools item 4 and 5and they of course right!. When i check their limitations, point 5:Programs start at offset 0x0800. Programs generated with the evaluation software may not be programmed into single-chip devices with less than 2 Kbytes of on-chip ROM.then its clear where this gap is coming from.So nothing broken or not a bug, this is exactly what suposed to be. All you can do now is to use different µC (with more ROM or external ROM) when you wish to stick on Keil/µV or use different compiler.

author: rohan-04
author_rank: Contributor
timestamp: August 21, 2013, 11:21:11 am
content: Right I guess I'm back to using eclipse and sdccSo I think Ill get these chips replaced with 89S51 and try again.

author: rohan-04
author_rank: Contributor
timestamp: August 24, 2013, 08:30:11 am
content: Good news, managed to get one of the controlled to blink an led, however other controllers with the same exact hex arent working, so i guess its just down to faulty controllers.Edit : Others working too now. Thank you for all the help.