my program stops when it gets to delay_ms

[Ringo42]

I'm using CCS PCM C Compiler, Version 3.223, 28885.
I have a couple identical boards with pic16f877a's on them. I programed them for the first time in a couple months and they would not run. So I stripped the program down to the bare essentials. Just blinking leds in b6 and b7. without the Delay_ms lines the code runs. I verify it with my O-scope since it is too fast to see. when I put in a delay_ms line then the code stops there and led1 stays on. What could I possibly be doing wrong here? It happens on both boards.
Thanks
Ringo


Here is the code

[cmdrdan]

In the #FUSES statement, change LVP to NOLVP and see if that makes a difference. There are several threads on this forum relating to the hazards of using the LVP fuse....

Dan

[Ringo42]

I use a LVP programmer, without that fuse I can't program. Been using it for years without a problem so far. The LVP pin is pulled low to keep it in that mode so it is not floating or anything.
_________________
Ringo Davis

[Ringo42]

If I comment out the delay_ms line then the .lst file changes much more dramatically then I expected. Whey would that change things way above those lines, and before main?
Ringo
without the delay

[Ttelmah]

The amount of change, is both expected/normal.
Basically, the optimiser is smart enough, that if you never use a 'delay', it does not generate the code for it, removing it from the memory. When you code 'delay_ms(1)', the code for the delay is called, and the code (which is actually generated at the delay statement line), is then present.
So the code that actually 'implements' the delay, is the twenty lines starting at address 4, and the 'main', gains the call to this.
The code looks 'spot on'.
It loops 6 times, round a counter, which counts 256 times, taking 3 instruction times per inner loop, and an extra four in the outer loops. It then loops 123 times, again taking 3 instruction times per loop, and repeats this whole operation, for the number of times passed to the 'delay' function. The time is then:
1/(20000000/4) = instruction time.

count = (((256*3)+3)*6 + 123*3) + 3 = 4998

total time (you need to add the call/return to this) = instruction time*4998

= 0.9996mSec

With the time for the call/return, this is just about as near as is possible.

So, there is nothing wrong with the code.
The possibility then is that something else is preventing the chip working. A 'classic' that produces this sort of failure, is not having a current limiting resistor to the LEDs, which then work if only turned on for a few uSec, but if switched on for longer, pull the supply rail down, stopping the chip...

Best Wishes

[Ringo42]

I can't imagine it is something wrong with the boards. I built a dozen of these and the other 10 have been running in a commercial robot for about a year. These are spares I use for testing code and have worked fine for the past year until I put them up for about a month and just got them down to test some code. and both are acting the same way. So if it is Hardware, then it happened to both boards at the same time.

It always stops running code at the delay_ms line. I even tried taking out the led stuff and setting pwm to 10%, then delaying and setting it to 90%. It does the same thing where it sets the first one, then just stops running and never sets the second one. The crystal is still running the whole time, what else could make the chip stop running code? I'm confused by this one. Eventually I'll change the chip out if it comes to that, but I'm hoping to find something before going to that extreme. It is a TQFP on a crowed board.
Thanks
Ringo
_________________
Ringo Davis

[rnielsen]

I've had this exact thing happen to me and after several days of frustration and several dents in my computer case(I only used a small hammer ) I found the problem was that I had an interrupt enabled but no ISR declared. Once I disabled the interrupt or put in a blank ISR the delay() function started to work properly. Check to make sure you have ISR functions for ALL enabled interrupts. Hope that helps.

Ronald

[Ttelmah]

OK. One thought. Maybe the compiler does not like having 'mixed case', in the fuse statement. If the watchdog was being left enabled, then with the delay present, it'd quickly reset. Are you sure the clock is 20MHz?. If the clock is not correctly declared, then the code will be incorrect in it's delays, and could wtchdog, before getting out of the first part of the routine...

Best Wishes

[Ringo42]

In this simple code I don't have any interrupts enabled (I'll remember that for later though). I'll try putting in a global disable tonight though.
_________________
Ringo Davis

[Ringo42]

I'll fix the watchdog code, maybe it is making it hang, but it is not resetting. In my PWM test once the pwm starts it does not stop, if the pic was resetting the pwm would stop right?
_________________
Ringo Davis

[Ttelmah]

It would _hiccup_, but the break would be tiny without the delay, and might not even be visible, unless you have a digital scope, with the ability to sync, on a longer gap between edges. With the delays present, it might sit permanently in the first part of the loop.

Best Wishes

[kam]

About 1 year ago, I was starting to program pic10f206's using Microchips ICD2 and mplab v7.30, and guess what?! The program would stop/crash whenever the delay_ms was used. Long story short, mplab was not programming the 206's WatchDogTimer fuse correctly, it was always ON, hense in the delay_ms, the WDT kicked in...

~Kam (^8*

[PCM programmer]

I installed PCM vs. 3.223, compiled your program without changes
and programmed it into a PicDem2-Plus board. It ran OK.
I had to jumper pin B3 to ground, through a pull-down resistor, because
of the LVP fuse. I also had to remove the ICD2 connector after
programming, because the ICD2 uses pins B6 and B7.

[Ringo42]

If it works on your board that sure makes it sound like HW, but on two identical boards? I'll replace the pic and see what happens.
Thanks
Ringo
_________________
Ringo Davis