Debugging problem with dsPIC, losing connection (30F5011)

[iggyboy]

dspic30 debug

I have stumbled upon an odd problem. I am trying to "develop" a led blinky on 30F5011 and the mcu keeps resetting itself.

I can program the chip fine, debugging with ICD2 works up to a point, then the device resets itself and the ICD2 loses connection. This usually happens after a "return" in the code, however not always and to me it appears as somewhat random. I rewritten the program and this is the current application:

int main(){

  while(1){}

}

#includes and config stuff are ok, I have setup the traps and enabled the trap irq, but those never occur unless I manually force (program) them, so they work fine.

Everything is ok, for a few seconds or so, afterwards the mcu stops working and resets itself, ICD2 says it can't enter debug mode. All peripherals are disabled. At the moment I am running it at the internal 7.37 MHz oscillator, all ports are inputs.

Single stepping generally speaking works, but after a random number of cycles the ICD2 loses connection. ICD2 is new and veryfied to be fully operational.

Compiler is C30. Forum on microchip is down, I use debug mode in MPLAB and the MAP file looks OK. Read the tech support on microchip site and still everything looks ok.

Getting rid of ICD2 does not help, in release mode withouth ICD2 the mcu seems dead.

So what is happening?

Help trully appreciated.

 

[x_zoli]

dspic33f crystal layout

Disable the watchdog, it might reset your MCU

 

[iggyboy]

#include p30f5011.h

This is the current configuration:

#include "p30f5011.h"

_FOSC(CSW_FSCM_OFF & XT_PLL8);  	//Run this project using an external crystal
                                	//routed via the PLL in 8x multiplier mode
                                	//For the 10 MHz crystal we will derive a
                                	//throughput of 20 MIPS(Fcy)
                                	//, 50 nanoseconds instruction cycle time(Tcy).
_FWDT(WDT_OFF);                 	//Turn off the Watch-Dog Timer.
_FBORPOR(PBOR_OFF & BORV_27 & PWRT_64 & MCLR_EN);	//power-up timers.
_FGS(CODE_PROT_OFF);	//Disable Code Protection



int main(void){
ADPCFG=0;
PMD1=0xffff;
PMD2=0xffff;
INTCON1=0b0000011100000000;

while(1){}

}


//=============================================================================
//Error traps

//Oscillator Fail Error trap routine
void _ISR _OscillatorFail(void)
{
	INTCON1bits.OSCFAIL=0;
}

//Address Error trap routine
void _ISR _AddressError(void)
{
 INTCON1bits.ADDRERR=0;
}

//Stack Error trap routine
void _ISR _StackError(void)
{
  INTCON1bits.STKERR=0;
}

//maths (Arithmetic) Error trap routine
void _ISR _MathError(void)
{
  INTCON1bits.MATHERR=0;
}

 

[blueroomelectronics]

dspic watch dog

Nope don't see any Horror here.

 

[iggyboy]

dspic30f5011 100nf

So if I understood that correctly, you think there is nothing wrong with the code?

 

[blueroomelectronics]

dspic30f5011 problem 100nf

You'll get more help if you post your question at least in part in the subject line. Urgent and Horror will get little help.

 

[iggyboy]

_addresserror(void)

Well it's a little late for that, but thank you for your constructive criticism.

 

[blueroomelectronics]

dspic crystal stops

You're welcome

 

[iggyboy]

dspic30f debugging not working

I have made a duplicate (different pcb layout) of the hardware and found that the 30F5011 still won't work, in fact, the new HW refuses to enter into debug mode at all. I have tried different HW, different oscillator settings, even different ICD2 devices (one is the newest, original ICD2 and the other is the famous clone from edaboard), different cable lengths and none of them work. Tried new MPLAB, tried even the latest C30, so now you know how desperate I am. All lines are toggling happily, everything looks ok, but the 30F5011 does not get recognised and can not be debugged. Supply is ok, oscillator lines are ok, soldering is ok, no shorts or broken traces, everything checks out as it should and the damn thing just won't work.

Man I trully hate the 30F5011 :|

 

[blueroomelectronics]

debug address trap + microchip

Might get a better response from the Microchip Forums. Lots of people use the dsPIC30F5011 with the ICD2, I've used the much smaller dsPIC30F3013 with my ICD2 clone and it debugs fine. I program in assembler though not C30.

Debug mode requires your OSC is running properly but allowing automatic failover to internal RC will also work as long as the config setting is there. Take out the OSCFAIL setting let it work till you debug it properly.

Also what's on your MCLR, PGC & PGD pins, is your ICD cable less than 8"
Do you have 0.1uf caps on every VDD & VSS pin?

Curious, you seem to be "new" with the PIC in general, why did you choose the such an advanced dsPIC30F5011; a somewhat difficult although powerful PIC for your project?

 

[iggyboy]

5011 dspic

Microchip forums have a very annoying feature. The search function does not operate as it should (somewhat erratic behaviour) and posting yet another ICD2 debug with 30FXXXX will make me feel stupid as they ask me "...did you used the search...?"

Your suggestions with the oscillator: I tried them already last week and they do help some devices connect, however debugging is still not possible as after a while the debugger loses connection again on device A, and fails to enter into debug mode at all on device B. But withouth fiddling with the oscillator the debugger wouldn't even recognise nor connect to device B. I don't think the oscilator itself should be involved when connecting and recognising the device (so the above effect is weird to me), but it defenitely has a cardinal role when debugging the device.

One of the first things I checked was the oscillator (it ran fine) and voltages on supply pins (analog supply too). Looking at the signals PGC and PGD, one can see the RC curve (the level on those pins has enough time to reach full scale voltage) and no coupling artefacts. Writing to pic is I think 2x faster as is debugging, judgeing by the length of the packets.

On device A I had supply pins very close to the supply pins. Two single 100nF (X7R) capacitors shared supply pins on the +Vio rail for the whole 5011 directly under the package. There was another 100nF less than 2cm away from the analog supply pins. The digital supply was filtered once with a LC+100n and the analog pins had yet another (same design) filter.

The oscillator fail never occurs, none of the traps does, unless I trigger them manually. But I will probably follow your advice.

I have two ICD2 cables. One is approx 0.5m in length and was used to develop everything we have and another which is about 15cm in length. Both work the same.

Oh, and on my PDC/PGD pins and nMCLR:

device A:
PGC: 4k7 pull-up (pin will be used for jumper when not debugged)
PGD: 4k7 pull-down (pin will be used for jumper when not debugged)
nMCLR: 4k7 pull-up, then 10k pull-up, then 1k pull-up than back to 4k7 pull-up.

device B:
nothing except the nMCLR pull-up

Curious, you seem to be "new" with the PIC in general, why did you choose the such an advanced dsPIC30F5011; a somewhat difficult although powerful PIC for your project?

What makes you think that? Why is 5011 supposed to be difficult?