18f452 will not start

[ipcas]

Hello,

I have a strange problem with the 18f452.
In some cases the processor will not start.
Our program is nearly 24k words (77%)
If we add only ONE Instruction to the Code (e.g. delay_ms), anywhere in the
program, the Processor will not start.
If we remove this instruction the processor starts absolutely reliable.
.
The startup code is:
0000: GOTO 5910
*

5910 is the Main() where we never get to.

Here is what we use:

PIC18F452 Rev 7
10Mhz Crystal
PLL
Very slow Power Up Front: 0 to 5 Volt in 11 ms
RC on MCLR R=47k C=100n (the same with MCLR on VDD)
PowerUpTimer
NO Watchdog
The Compiler is CCS Version 3.112

Please Help. We are very confused.

Regads

[Ttelmah]

[Mark]

Ask CCS nicely if they will let you have the lastest version since the old one had problems. If they won't, send me the code and I'll compile it for you and send you back the hex file. If it works, then I would upgrade the compiler.

[rnielsen]

I've had a problem similar to this in using a delay_ms() command. My problem was that I had a timer interrupt, enable_interrupts(INT_TIMER1), listed but I had commented out the service routine for that timer and forgot to comment out the enable command. Every time I would hit a delay command the processor would freeze. Make sure you have a Interrupt Service Routine defined for each interrupt you have enabled.

I lost some hair over this one from pulling it out.

Ronald

[bdavis]

I thought I read something about issues with using the ICD if the PLL was enabled. You may want to try running at 10MHz without the PLL to see if that works.

[ipcas]

I have no Problem without the PLL. even with 25Mhz.
But, if i add an NOP at the Address 0 and then the JUM Main
anything is OK.
It seems that the cpu ignores the first instruction.

Is there a way to modify the Reset-Code in the -C- source ????

[Guest]

With this statement you can move the reset vector:

[benres]

I just ran into this problem using the PLL mode with an 18F242. About 30% of the time, the processor doesn't start. I have good powerup time, and the 10MHz XTal is about 4.5v p-p (Vcc is 5 volts). Startup is perfect with the PLL disabled. I tried swapping crystals and caps, and it makes no difference.

Adding the line

#Build(reset=0x0002)

fixes the problem and now everything works great.

I have two questions:

1) Can anyone provide additional information about this bug and why this fix works?

2) Is there any reason to NOT add in this fix? If this is what it takes to make PLL work, then wouldn't you ALWAYS want this line of code?

Thanks,

- Ben

PS: I NEVER would have figured this out on my own.

PPS: A paralled thread is going on in the Microchip forum at: http://forum.microchip.com/tm.asp?m=49841&mpage=1&key=pll&anchor#49856

[dyeatman]

This is a Microchip problem. Here is where I first related it on this board.

http://www.ccsinfo.com/forum/viewtopic.php?t=20325

[benres]

Thanks for the response, but I'm having a different (and far more evil) problem. Yes, enabling and disabling the PLL doesn't take effect until the chip is power cycled. However, once the chip has been power cycled and the PLL changes are in effect, the chip should start every time. The issue you describe only happens once.

The problem I'm seeing is both intermittent and persistent. It's doesn't go away after a power cycle, and it only happens about 30% of the time.

We've now tested this "#build()" fix on about a dozen boards, and it fixes every one of them.

Before releasing this code, however, I'm hoping to get some confirmation this fix won't cause even larger problems. If this fix is indeed harmless, why isn't it part of the compiler?

[asmallri]

Have a look at the .lst file for both versions and have a examine what is happening in low memory. It sounds like you observing a symptom as opposed to determining the root cause of the problem. If it is only a symptom you are playing with them some other manifestion of the root problem is likely to catch you out.
_________________
Regards, Andrew

http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!

[dyeatman]

I just finished the third of three projects using the 18F452 (I use the ICDU40 for development along with an external 9.216MHZ oscillator and PLL enabled) and did not see any startup problems at all (except for the power cycle issue I stated earlier) so using an Xtal seems to have something to do with it. I wonder if this is a silicon revision issue. Have you contacted Microchip?

[PCM programmer]

1. What are the capacitor values that you're using with your crystal ?

2. What is the Manufacturer and part number of your crystal ?

3. What is the silicon rev of your PIC ?
(ICD2 will display this in the MPLAB output window).

4. What is your version of the compiler ?

5. Post a small test program that demonstrates the problem.
Show us exactly how it fails. (ie., "it fails to execute this printf
statement properly. I only see the first three characters").
Show all compiler directives and pre-processor statements.
ie., #fuses, #use delay(), etc.

[benres]

I posted some additional information, .C .LST and .HEX files with and without this "#build()" fix. This post includes crystal specs, rev, version, etc.

http://web.media.mit.edu/~benres/picbug/

I also looked for older errata, and this is the closest I found:

http://ww1.microchip.com/downloads/en/DeviceDoc/80129g.pdf

Testing shows this "#build()" fix to be stable and have no other adverse effects. Yet, strangely, I'm still not comfortable closing this bug. I'd like to have a better understanding of why this fix works, and if there's any reason to not include it in ALL code.

Thanks,

- Ben

[asmallri]

I tried downloading this link but received a page not found error:

http://web.media.mit.edu/~benres/picbug/test_noFix.lst

I have a couple of hundred of these PICs in the field - Multiple applications, copletely different code sets. Not one of these PICs has a NOP at location 0 and none of them have the problem you describe.

If the problem is with the hardware then I would be looking around the power on reset circuitry. Failing that a code bug either introduced by the application software or the compiler.
_________________
Regards, Andrew

http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!