MCLR reset due to programming logic?

[PCM programmer]

Disconnect the motor from the board and set it aside. Now run your
tests. If the PIC doesn't reset or lock-up, then the problem was caused
by current or voltage transients, or voltage droop, due to the motor.
Then you need to look at the hardware design. There could still be
some software problems in addition to that.

[santosh.manicka]

I haven't checked that yet...but I found something else interesting. My code has the following #defines-
#define PROFILE_DATA_SIZE 1024*8
#define FLASH_DATA_SIZE (PROFILE_DATA_SIZE+1024)
#define FLASH_DATA_END (PROGRAM_MEMORY_SIZE-1)
#define FLASH_DATA_START (PROGRAM_MEMORY_SIZE - FLASH_DATA_SIZE)
#define FLASH_PROFILE_START (PROGRAM_MEMORY_SIZE - PROFILE_DATA_SIZE)

#org FLASH_DATA_START, FLASH_DATA_END {}

NOTE the #org at the end.
Now, when I comment/uncomment out a few lines of code (NOT the #defines above but other parts of the code) and at the same time increase/decrease the value of PROFILE_DATA_SIZE above, it affects the way the program resets - sometimes the program doesn't reset all, at other times the program doesn't even start running and a many other different behaviors.

NOW, the code doesn't even occupy 50% of the program memory (128KB) and the above #org allocates just 10KB at the max.

Any insights into why this could be happening?

[santosh.manicka]

Yes, by disabling the motor, the problems don't occur. Even then the program reset just once but that was found to be due to the usage of the math function 'pow'. When I replaced it with atan and cos, it is working fine BUT only with the motor disabled. Enabling it resets the program.

[santosh.manicka]

I have the updated circuit diagram here - http://www.esnips.com/doc/db317828-81a9-4281-94f6-7f5ae4736656/CircuitDiagram-updated

Can anyone help me figure out what could be wrong with the motor enabling causing the program resets?

Cheers.

[PCM programmer]

I can't see your image. It just says "Converting to iPaper...." and then
it says "Document failed to convert".

I suggest using a more simple image posting host. Use one that does
not require conversions.
Also post a clear photo of your board and the motor connections.

[santosh.manicka]

Sorry abt the earlier post.
Try this link again, please - http://www.esnips.com/doc/4a4ba99e-1e0c-483a-b746-240a131e6e4e/CircuitDiagram-updated

If you scroll down a bit, there is an option to download the file. The file is a PDF, so you can also zoom in and out the file.

I don't have a camera right now, so I can't post the images of the board and the rest of the set-up now. I can get it done tomorrow.

Cheers.

[newguy]

I'd install two TVS (transient voltage suppressors) - one on your 5V PIC/logic supply, and the other on your "PWR" supply, close to the motor. Choose something with a rated voltage just a bit higher than the rail it is connected to. These are the TVS's I typically use: http://littelfuse.com/data/en/Data_Sheets/ML.pdf

I'd also install small series resistors between the PIC and the motor controller - 100 ohms should be plenty. Definitely install these on the SCL and SDA lines as well as the CCP4 and CCP5 lines, and they may also be necessary for the AN8 and AN9 lines.

The motor control chip you're using - the MC33887 - does it include flyback diodes on the motor drive outputs? If the above changes don't help, it may be necessary to add external flybacks.

The ICSP line leading to the MCLR input on the PIC - is it short? Is is run parallel to any power traces, particularly the "PWR" rail? It's possible (don't know how likely) that noise on the supply rail (from the motor) is coupling into that line and causing resets. Can you disable the MCLR enable fuse and see if the number of resets you're seeing decreases?

Hope this helps.

[avro698]

Try linking out diode D1, maybe it is dropping too much voltage across it and affecting the MCLR pin.
Use an oscilloscope and check what is happening at the output of the regulator. If the motor draws a large amount of current when it starts and the voltage dips at the output of the regulator it may cause you problems similar to those you are experiencing, especially brownout.

[PCM programmer]

I would remove the diode on the MCLR line. I don't have that on any
of my designs. I just have a 10K resistor to Vdd. If you're using
the CCS ICD-U40, then use 47K.

I would modify the board and add a 100 nF cap on every Vdd pin (5 pins).

If you know the amount of current that the motor uses, substitute
resistive loads for the motor. i.e., put two resistors on the motor
driver pins. See if the system resets. If it doesn't, then the problem
is likely caused by the inductive load of the motor. Or the commutator.

You need to isolate or suppress or reduce the current and voltage spikes
that the motor puts into the system. Your layout guy is going to have
to do another layout.

[Vintermute]

The programmer is an MELabs serial programmer, the diode is there because of their advice here: http://www.melabs.com/support/icsp.htm

I have used this programmer, with exactly the same programming cable on numerous PIC based boards that I have designed and never had any problems at all. They all used the same connection system (i.e the diode on MCLR)

Although the decoupling capacitors are not ideal I have six of these boards with their motors and have been using them myself without any problems at all - no unexpected resets or anything else. The one Santosh is using has probably seen the heaviest use and been run for the longest periods but I sent him one of my other boards and he has had exactly the same problem. The code he is using is an extensively modified version of the code I am using which has added a lot of extra variables and functions. I have taken a look at it and can't see anything that is obviously wrong (but I'm not the best programmer in the world ;).

These problems have all seemingly begun to manifest after Santosh had been using the device for several weeks, and had made successive modifications to the code. This did suggest a degradation in the components but now he has tried a different device with a different power supply and is still getting the same problems.

I am about to test all his code on a device I have myself to see if it could in any way be related to his computer - there is a lot of serial communication going on between the device and a windows application.

He was getting a Watchdog timer reset cause the other day as well despite the fact that there is no watchdog timer enabled.

Could it be a fault with the programmer?

[Vintermute]

We may have uncovered the problem.

The getenv("PROGRAM_MEMORY") function should, according to the CCS help files: Return the size of memory for code (in words)

However when we use it we get 131072 returned for a PIC18f6722 which has about 128kbytes of flash so according to the CCS documentation the function should return 65536.

This means that the calculations and locations for the flash memory we have reserved for data are wrong. This was compounded by an error I made when porting the code from an earlier design that only had 64Kbytes of flash - I was using an int16 to store the start addresses of various data blocks in flash, I should have been using an int32.

The code still appeared to work OK on the new device but presumably when Santosh started adding new code it ran into the reserved area in flash and started to cause these errors - at least that is the hypothesis.

Does the problem with the getenv function mean there is a compiler bug or a documentation error?