@dchisholm LOL!
That tube stuff from the… whenever… still worked into the early '90’s; in lots of areoplanes.
We’re getting seriously off topic, but I never used tubes (valves to my friends across the pond), except for PMT tubes. But those don’t so much glow, rather they detect glows. (Single photon sensitivities.)
I guess that makes me an older young’un. 
1 Like
As often mentioned in threads dealing with the “not connected” family of error messages, the error may not be at the component you pick up and move to observe the rubber-banding. Rather, the error may be on the other end of a connection to that component.
Dale
I have a memory that different manufacturers have different ideas about how to number the pins on an SOT-23 package, so putting pin numbers on a schematic may not help.
As for the question of which physical pin (regardless of how they are numbered) connects to which semiconductor element (B, C, E, etc) . . . . There must be a bar in Hell where the guys who UN-standardized the SOT-23 connections (and the TO-92) all hang out. And every time they hear cussing because somebody probed an “E” pin, when they thought it was the “B” pin, they raise a glass and proclaim “Caught another one!”.
Dale
Maybe the 737-MAX needs a few more 12AX7’s!
Around 2000, my oldest son had my Dynaco Stereo 70 prominently displayed and operating in his college dorm room. From what he said, the “Wow!” factor among his buddies was quite high.
Dale
GaN does the whole trick. Zero trr!
Ok thank you for the tip about the highlight net tool, it permits me to find that one of my big component ( hundreds of pins) was designed in a 50mils grid but in its subsheet it was not aligned with the 50mils grid. I moved my component to align it with the 50 mils grid but the incriminated nets still generate warning in ERCs Anyway, long story short : problem stays the same
Here is some screenshots of a dense zone of warnings. I use local nets for more readability.
The first screenshot is an “ERC warning point dense zone”(JTAG connector)
The second one shows the only other location in the schematics where the nets are used
The third one is the “origin” of the nets, in the “module” subsheet.
I’ve highlighted one of the net for more clarity.
Is there an email adress where can I send the project ? I prefer to share only screenshots on the forum but If I send the project I will only send it to developers ( it’s not a personal project but a company one , sorry guys …). But this will be my last despair option !
Last but not least, thanks for all your answers ! It’s nice to see great reactivity on a forum 
This is odd nut to crack. Another troubleshooting thing to try would be to create a netlist. Search for “JTAG_TRST” and see what pins are in that net. If the netlist reports all the pins that you expect, it might be time to up this to an actual bug report.
Ok, this is probably a silly question of mine… After moving your big part back onto the grid, you did re-run ERC, right? (ERC flags aren’t automatically cleared when they are addressed…)
There was a bug some time back that muddled up things when using the annotation tool. I think single unit symbols had the chance to be converted to unit number 0. Which resulted in them being ignored by both ERC and also the netlist export.
The problem is finding out which of the symbols is the true problem maker if this is the case. Without the file we might not be able to help at all here. Which means you will need to replace symbols one after the other and see if that fixes anything (with using manual annotation instead of the automatic one.)
Yes I rerun ERC every time I change a component, rewire something, etc…
I just had to ask. But, I expected your answer.
Ha ha no silly questions no worries
Ah, yes. Sometimes the “NC” pins of chips are used for some unspecified testing calibration and you should never ever connect anything to it. Sometimes there is not even a bond wire connected to it. And this can be good to know, so the pad can be used as “extra room” to route tracks. Which is also a good example for having a NC pin visible in the schematic.
Back to the original topic.
You seem to have some experience with KiCad, and also the absence of the little squares in your screenshot suggest that the pins should be connected.
I am sort of getting a feeling that this may be a bug in Eeschema. For further diagnosis it helps to upload the schematic (with -cache and maybe some other files) so others can have a look at it. I’m not in the right mood to do this myself right now though.
Recently when working on a PCB, I noticed a coordinate ending in a lot of 9’s, which clearly looked like some kind of rounding error. Could Eeschema be confused by similar rounding errors?
This was reported over on the bug tracker including the file. It was damaged and 5.1.2 was able to repair it by running the annotation algorithm.
My experience is from breadboarding. I have ruined a number of mcu’s and I don’t know why. I ‘think’ my controllers may have suffered inductive spikes from my motors.
Several of my boards didn’t work properly after a while and I was puzzled. I had just gotten a really basic oscilloscope and saw that I could not get a clean square wave at 20Khz. I replaced the mcu and it worked fine.
At any rate opto’s are easier to replace than mcu’s. Until I figure out what I’m doing wrong I will avoid sharing grounds between my microcontroller and my motors. In addition, for my next pcb, I want to have separate power switches for the mcu and the motor driver module.
Breadboards are really great for quickly trying things out, but they are not very reliable, and that’s OK, as long you you treat them as such.
Breadboards and power electronics also do not work wel together.
With motor controllers you have fast transients in voltage and current, and these have high frequency components. And at high frequencies, every wire becomes an inductor. Some of the modern MOSfets switch very high currents so fast, that the inductance between the chip itself and the outside of the housing is specified in the datasheet.
When you change the current through an inductor, it generates a voltage, and such spikes have plenty of energy to kill microcontrollers. If such a spike occurs in the GND lead between the uC and the motor controller, then all connections between the motor controller and the uC are affected!
Part of the solution is to use star grounding at the GND of your motor controller. That way the wire between the motor controller and your uC never sees such peeks. But if your uC is connected to GND (Osciloscope, programmer, USB to PC whatever) then such things come back.
1 Like
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.