USB CDC restarts my PIC

[Damaso]

I'm using a PIC24FJ128GB106 to implement a controller for some complex electrochemical analysis. For that I need to use one of its timers, a usb cdc conection and plenty of its I/O pins. My problem is that the pic restarts during the usb communication.

The firmware is pretty extensive but basically it configures the experiment, takes lots of meassures using an external ADC and, when the timer interrupts happens, it averages the meassures and sends the result via usb. Then it changes the condition of the experiments and continues with the same behaviour.
Depending on the experiment parameters, the usb packets are sent ranging from tens to hundreds of millliseconds, and no timer interrupts happen during the communication phase.
The communication is simply 16 consecutive usb_cdc_putc() to send different values and control characters.
I know for certain that the code (excluding the communication part) works.
I also made a simple program that reads a character from the hyperterminal and then sends packets continously. It works flawlessly.
But when I try the whole code, after some characters are sent, the pic suddenly restarts during the communication phase (between putc intructions). It doesn't happen after the exact number of characters but it usually happens soon. I also noticed some transmission errors that should happen very often. I don't know if there are some conditions under which the usb firmware restarts the pic due to a fatal error or something llike that. Is it possible?
The hardware part doesn't seem to be the problem. I have the required capacitors and I even tried directly connecting an external PSU to generate the 3.3V, excluding flickers in the MCLR line.
Has anyone ever found something similar? Is it possible that the cdc firmware resets the pic?

[temtronic]

Have you confirmed by testing that it IS the PIC side of the communications that is at fault?

USB isn't ultra reliable.

What's going on inside the 'logging' PC?

Did you run another PC to 'simulate' the data from the PIC and connect to your 'logging' PC?

I've had cases where the PC was at fault as it was automatically downloading 'updates' to a program and 'store time' from my PIC application...

So please check that it's NOT the PC .

hth
jay

[Damaso]

I don't know how the pc could force the pic to reset during a usb communication. I used a usb sniffer and I didn't noticed timeouts or anything similar. Suddenly the pics resets and then the pc side sends some "pipe fault" or similar error because the pic side isn't answering

[Ttelmah]

The place to start is to test restart cause, and get an idea of what might be triggering the reset.
The obvious one is stack. Have you got more loaded than the default?. The default allocation is too small if you have a reasonable number of printf's, or similar fairly heavy users. Guess would be that the USB is using several levels, and just happens to be taking it over the limit. Remember this is _not_ the 'call stack' reported in the compiler listing. The PIC24, and 30, use the stack for variables as well, with something like a maths operation, often putting ten values on this _each_. Do a long print, or maths function with several temporary variables, and a lot of stack is used. Have an interrupt call, right when the stack is nearly full, and the default, unless you have enabled extra trapping, is for the PIC to reset.....

Best Wishes

[Damaso]

I'm only doing usb_cdc_putc() and no printf, but I guess the stack could fill as well. I've never debugged the stack, how could I see the amount of stack used at a precise moment using the pickit3 debugger?
Should I try with #build (stack=1024) or #build (stack=512)?
Is there a direct way to know the restart cause by debugging?

[Ttelmah]

Read the restart_cause value after the reset.

The USB functions themselves use quite a few stack levels.

If enlarging the stack fixes it, you have your answer.

Best Wishes