Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

dsPIC30F4011 and ICD2

Status
Not open for further replies.

dknguyen

Well-Known Member
Most Helpful Member
THe ICD2 is not recognizing my dsPIC. I am not sure why. I wired up the pull-up resistor to MCLR, and applied power to all the Vdd/Vss and AVdd/AVss pins with bypass caps, as well as running out the PGC,PGD, MCLR, Vdd, Vss lines to an ICD2 jack. I select the ICD2 as the programmer in MPLab as well as the device but it just doesn't seem to be get a device ID from the PIC when I choose "connect". I tried it with another PIC18F (modified to it's pins of course as well as changing the selected device), and it still didn't recognize it, but the universal programmer verifies that PIC18 is working (but it doesn't support the dsPIC so I can't use it). I also selected the configuration bits to use the default PGC/PGD pins as the com port, and not some alternate ones (but it shouldn't matter since my PIC only has one PGX pair of pins anyways, only the EMUx pins have alternates.

Am I missing something subtle? I am pretty sure I got everything in the manual but it still isn't working. I remember to select the right device and upload the right OS to the ICD2 and the ICD2 passes it's own self check so it seems to be working.

What I described is exactly what I did, nothing more. Did I miss something? I shouldn't be having the problem with the hardware since it's the barebones wiring but it's just not working.
 
Last edited:
Have you measured the supply voltage with the ICD2? It is under programmer - settings - voltages, I think. You can use that to check the PIC power is getting through to the ICD2.

If that is OK, make sure all the connctions are correct, and then look at the MCLR, PRGD & PRGC with a 'scope, while attempting to program. There should be 3V square data signals on all of them. If not, you might have shorts or too much capacitance on the lines.

I have programmed a wide range of PICs with an ICD2, (10F200 .... 24FJ32G002) and the only problems have been down to connctions, power supply or something stopping the ICD2 from asserting the voltages.
 
Diver300 said:
Have you measured the supply voltage with the ICD2? It is under programmer - settings - voltages, I think. You can use that to check the PIC power is getting through to the ICD2.

If that is OK, make sure all the connctions are correct, and then look at the MCLR, PRGD & PRGC with a 'scope, while attempting to program. There should be 3V square data signals on all of them. If not, you might have shorts or too much capacitance on the lines.

I have programmed a wide range of PICs with an ICD2, (10F200 .... 24FJ32G002) and the only problems have been down to connctions, power supply or something stopping the ICD2 from asserting the voltages.

I know it's not shorts and not something stopping the ICD2 from asserting (at least not MCLR anyways). Maybe it really is capacitance or something. I''l try again this week...we already got a one week extension because none of the lab equipment supports our uC.
 
I read on the Internet that other people had the same problem and several hypotheses were made:
- cross-talk between PCD and PGC lines.
- power not sufficient for dsPIC30F programming operations.
- troubles after using ICD2 debugger. Have you programmed the uC succesfully before experiencing that issue? In that case, I believe that a "bulk erase" can bring your chip back to its original state (supported if Vdd>4.5V).
- ...
 
eng1 said:
I read on the Internet that other people had the same problem and several hypotheses were made:
- cross-talk between PCD and PGC lines.
- power not sufficient for dsPIC30F programming operations.
- troubles after using ICD2 debugger. Have you programmed the uC succesfully before experiencing that issue? In that case, I believe that a "bulk erase" can bring your chip back to its original state (supported if Vdd>4.5V).
- ...

I've programmed them before but using a MELabs programmer. THis is my first time using my ICD2 as a programmer or as a debugger. It's been sitting in the closet forever.
 
Do you have pullups on the PCD and PGC lines? If you do, it won't work.
 
Are you using USB or RS-232 to connect your ICD2 to the PC? If you use RS-232, you will need to power ICD2 with 9v power supply. If you power your PIC via ICD2 you will need power supply connected to ICD2 even if you use USB.

The next possible cause for your symptoms is Windows device driver for ICD2. Look at the MPLAB's release notes for the explanation how to fix that.

Also, check if you can use ICD2 in debugger mode with your PIC18. You will
need working clock on your micro - configure internal clock if necessary. If not, most likely your ICD2's output drivers are dead.
 
felis said:
Are you using USB or RS-232 to connect your ICD2 to the PC? If you use RS-232, you will need to power ICD2 with 9v power supply. If you power your PIC via ICD2 you will need power supply connected to ICD2 even if you use USB.

The next possible cause for your symptoms is Windows device driver for ICD2. Look at the MPLAB's release notes for the explanation how to fix that.

Also, check if you can use ICD2 in debugger mode with your PIC18. You will
need working clock on your micro - configure internal clock if necessary. If not, most likely your ICD2's output drivers are dead.

I'm using USB and have external power going to the board itself. This is a brand new ICD2- could something be wrong with it? Because we've already gotten a one week extension just because the damned thing won't work. The PIC18 isn't mine so I would have to find that person again. Perhaps I should hook up an oscilloscope to the PGC and PGD pins to see what they are doing?
 
Check if Windows driver is correct. It's very easy to install the wrong one. Look in the MPLAB release notes - there is a procedure for deleting the wrong driver and installing the right one.

Also, paste here what is printed in MPLAB "output" window when you try to connect it.
 
I isntalled MPLab and C30 first. After that I plugged in the ICD2 and it kind of installed itself. THe ICD2 also passes it's self test and all so it seems like I can communicate with the ICD2, just not the uC. Would the wrong driver still allow the ICD2 to pass a self-check and not recognize the IC? THe PC is in the lab at school right now so I'll post the stuff when I get there (maybe, the PC isn't connected to the net and I don't have a USB key).

I found a copy on the net though what happens:

Code:
Connecting to MPLAB ICD 2 
...Connected 
Setting Vdd source to MPLAB ICD 2 
ICDWarn0020: Invalid target device id (expected=0x101, read=0x0) 
...Reading ICD Product ID 
Running ICD Self Test 
...Passed 
MPLAB ICD 2 Ready
 
Code:
ICDWarn0020: Invalid target device id (expected=0x101, read=0x0)

I'm playing with my ICD2 right now. It gives this diagnostics when PIC is not connected to ICD2 or when it's connected but not powered up.

At that point I'd start checking connectivity :). I made couple snapshots of PGC and PGD pins just after pressing "Connect" in MPLAB "Programmer" dropdown so you know how they should look like.
 

Attachments

  • pgc_and_d_analog.png
    pgc_and_d_analog.png
    6.4 KB · Views: 191
  • pgc_and_d_digital.png
    pgc_and_d_digital.png
    3.7 KB · Views: 197
After 30 hours of debugging and 3 of those hours being helped by a TA, I found the problem...the PIC wasn't pushed into the breadboard hard enough- hard enough so that all of the pins I would normally measure to check if it's connected made contact (like power pins and reset), but none of the others.

BAAHHHHH

That's probably not as bad as noticing the power isn't on, but my record for that is two or three hours....not 30 hours.
 
dknguyen said:
After 30 hours of debugging and 3 of those hours being helped by a TA, I found the problem...the PIC wasn't pushed into the breadboard hard enough- hard enough so that all of the pins I would normally measure to check if it's connected made contact (like power pins and reset), but none of the others.

Yet another reason for NEVER using breadboards! :p
 
Nigel Goodwin said:
Yet another reason for NEVER using breadboards! :p
Yeah I don't use breadboards at home either...but this is school. I should get some wire wrapping stuff.
 
Perfboard and wirewrap? TO be honest I've always just had the PCB fabbed and then green-wire it when I get it. It's cost me a bunch of money a few times when the mistakes were unfixable. Just too many SMD components to breadboard or wirewrap nowadays :(
 
Last edited:
Is it fair to blame the problem you were having on the breadboard when it was user error?
dknguyen said:
Yeah I don't use breadboards at home either...but this is school. I should get some wire wrapping stuff.
Now that would be a step in the wrong direction! If you want dependable prototypes make a PCB or do point to point. The nice thing about using PCBs to do your prototype is that the 2nd, 3rd, etc version (or copy) of the board go a lot faster then the first. The layout gets better with each revision too.

The system Nigel uses is a good variation on point to point wiring (veroboard?).

I use breadboards because they allow my students to rapidly construct circuits. Once they know which of the soldering iron is up, they only use breadboards when they need to play with a few components.
 
Last edited:
3v0 said:
Is it fair to blame the problem you were having on the breadboard when it was user error?
Now that would be a step in the wrong direction! If you want dependable prototypes make a PCB or do point to point. The nice thing about using PCBs to do your prototype is that the 2nd, 3rd, etc version (or copy) of the board go a lot faster then the first. The layout gets better with each revision too.

The system Nigel uses is a good variation on point to point wiring (veroboard?).

I use breadboards because they allow my students to rapidly construct circuits. Once they know which of the soldering iron is up, they only use breadboards when they need to play with a few components.

Just PCBs cost a lot of money. Bleh. This was just a quick "Hello WOrld" assignment so a breadboard was used and I spent 30 hours debugging a chip that wasn't plugged in amidst 2 midterms, a lab report, 4 assignments, a presentation, a report, and ballroom dancing. I'm only taking half a course load but somehow the stars aligned and everything feel into the same 3 day period.
 
dknguyen said:
Just PCBs cost a lot of money. Bleh. This was just a quick "Hello WOrld" assignment so a breadboard was used and I spent 30 hours debugging a chip that wasn't plugged in amidst 2 midterms, a lab report, 4 assignments, a presentation, a report, and ballroom dancing. I'm only taking half a course load but somehow the stars aligned and everything feel into the same 3 day period.

I understand. Then the breadboard was the right thing. Like I said, it was user error. You can not blame that on the breadboard. ;) You TA should have spoted this earlier. Lets blame him:) But for the most part **** happens.

When I was getting started a friend and I build a 3 channel light controller that hooked to a TRS80. It worked fine on the breadboard execpt for a bit of crosstalk. The handwired board was DOA. Due to a lack of funds we had to rob the breadboard to build the hand wired board. On our schematics we had failed to show the line to hold the reset high on the Z80 CTC (counter timer chip). We spent about the same time as you did digging for that error. To this day the phrase "NMOS does not float" is burned into my brain.

When you do get to more complex work:
With the right supplies and equipment you can make a toner transfer PCB from layout to finished board in a few hours. Any school teaching electronics should have, or get, a small CNC for drilling boards. With CNC drilled holes the board fab time (not including layout and population) can be well under an hour. The key is that you get the right stuff instead of trying to keep cost down by using an old clothes iron and mystry paper. Not that these things can not work. They can, but it is often takes time to get the right combo/formula. IMHO more time then it is worth.
 
Last edited:
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top