Importing Eagle Schematic of Adafriut Gemma M0 problems


#1

Hi there,
I’m trying to import an Eagle project for the Adafruit Gemma M0 board from Adafruit’s github page *(https://github.com/adafruit/Adafruit-Gemma-M0-PCB) so I can mostly just grab the board outline and hole placements so I can build myself a small addon board for a home project.

The import went well… even though I took the six layer original board and deleted all but the top and bottom layers, and removed all the components except the six holes around the edges. But now when I try to run the ERC checks, I get errors like:

ErrType(4): Conflict problem between pins. Severity: warning

  • @ (8.250 in, 5.570 in): Pin 1 (Passive of component R2 is connceted to
  • @ (9.600 in, 3.300 in): pin P$1 (Unspecified) of component GND1 (net 1).

and I’m at a loss on how to fix this properly. I’ve got a quite a simple schematic of just some transistors, resistors, input pins and an output IR LED.

So my questions are:

  1. whats the best proces sto go through to resolve this issue?
  2. should I just rename the pin P$1 to P1 and see what happens? If so, what’s the best way, using the schematic editor?

I wonder if the real problem is that I left in the schematic the definitions of the holes (pins really) for the device. Would it be even better to just nuke the labels and then just re-add them by hand?

I’ve included the various file I think I need to show these errors. Sorry I’m so clueless, trying to learn KiCad and design at the same time!

John

Adafruit Gemma M0.pro (928 Bytes)
Adafruit_Gemma_M0-eagle-import.dcm (51 Bytes)
Adafruit Gemma M0.kicad_pcb (31.0 KB)
Adafruit Gemma M0.net (10.0 KB)
Adafruit_Gemma_M0-eagle-import.lib (58.3 KB)
Adafruit Gemma M0.sch (10.6 KB)


#2

The problem is that one of your components uses pin type unspecified. This pin type always throws a warning in the default ERC setup. (No matter what you connect it to)

The green arrow simply points to one of the places where there is a problem.
The problem is the SEWTAB-ALIGATOR symbol. Change its pintype to passive and this problem should go away.
Use crtl+e on top of one of these placed symbols. Change the pin type via the pin settings dialog to passive. Save the lib and re run ERC.

You will then only be left with this one: ErrType(3): Pin connected to some others pins but no pin to drive it


The pin number P$1 is ok.


#3

Rene,
Thanks for pointing this out! Makes perfect sense to me now why this was a problem. Now looking at the other two types of errors I now see, do I need to actually care about them since the board really will be connected to another board providing the power, etc?

For example, the 3.3V pin in the upper right does have a type of power input, so I would think it’s ok… is this an error I can ignore?

I’m pretty sure ignoring the ErrType(2): Pin not connected for the one pin I’m not using at all is just fine, and I don’t really want to tie it to ground or anything like that…

Thanks again!
John


#4

Ok, I think I’ve actually found what I needed to do here, which is to provide the PWR_FLAG in three places to properly show that there will be power, even though it’s not connected up to anything.

I’m still a little confused in my understanding of why putting a PWR_FLAG on 3.3V pin doesn’t make the errors go away for the GNDs off my resistor dividers in the schematic.

But what I’ve done fixes all the errors and warnings so I think I’m set now.

Next step, trying to get it actually created in OSHpark!

John


#5

It has a hidden power input pin. Such pins are global labels. See my FAQ articla about Electrical type of schematic symbol pins for more details about that. (section "invisible power input pins and the link to stackexchange)

Use the “intentionally not connected” thing for that (blue cross in the right toolbar)

The power flag is per net. You need it in every net that has a power input pin. This is to ensure that you have your pcb powered correctly.


#6

Thanks for all your help! I’ve now run into a new problem, where my imported Eagle board suddenly adds in two more pads when going from the schematic to the pcbnew (I wrote gEDA by mistake, I promise!) design part of the workflow.

I suspect it’s because the naming in Eagle is confusing something in the netlist generation. Is there anyway in pcbnew (not gEDA!) to edit the netlist, or examine it more closely to see what’s going on?

Basically, the 3v3 pad is now duplicated, and gets moved. Resetting it is a total pain, and I don’t want to have any alignment errors if at all possible. It also looks like the B0 gets confused with B3 as a pad as well. I’m not sure how to address it.

Looking at the list of Nets in my design, I think I see where they have come un-hinged, but I really don’t know Kicad enough to know how to A) nuke the bad stuff, and B) associate with the proper stuff. Here’s a (hopefully good) picture showing the issue.

Net 000 has all three pads in it, which aren’t associated with any other nets, but you can see how the two pads to the outside are associated properly, but aren’t the pads they’re supposed to be. I put them next to the pads at the 9pm and 7pm locations to show what I wanted.

I think I need to go back into the schematic and double check my nets and make sure they’re really the way the need to be. The key for me though, it to not move any of the six pads around the board, since those are the mounting holes I need to stay aligned with.

Is there a way to setup a template board from an eagle import maybe? I just want those six pads on a two layer board which I can them import into a regular Kicad schematic. Sorta like having a breadboard template to layout on. I guess I need to do more reading.

Thanks again for all your help!
John


#7

I had to double check to make sure you meant Kicad?


#8

Yes, I mean the PCB editor tool in KiCad. Brainfart using gEDA there, I meant to say PCBNEW


#9

I don’t have a direct answer to your original question but remember that these files are text base so you can look to get hints or make corrections there if needed. Just make a backup of the file first.


#10

That indicates the SCH info, has a somehow different footprint tag, so pcbnew adds a footprint, and connects to that, not understanding that the existing footprint is valid.

Open the NET export from SCH, and the pcbnew file in an editor, and look at the footprint descriptions, including the tstamp and path fields.

You can edit the NET to make a new net file, and try import of that, until the edits make the bonus-added parts go away.