I just reopened a schematic in Rev 6 to make some changes. After making a few of the changes needed I ran an ERC which produced 100’s of errors on a previously error free schematic. At first I thought it was additional error detection but digging deeper it appears that rev 6 simply read the netlist incorrectly. One of the problems is the buses which are scrambled and duplicated
As you can see in the image the highlighted net has shorted *SPI_SEL7 and *SPI_SEL9 together and renamed them to *SPI_SEL13. Rev 5 has them as not only distenct signals but named correctly.
Is there some sort of upgrade process for older files to avoid this, or maybe a new version that correctly reads the older files?
The screegrab you posted does not appear to include a wire type of “Bus”. Also, the label names are not consistent with “Bus” syntax.
My situation with an upgrade of KiCad files from V5 to V6 also included an OS crash/re-install. I did not like it, but I manually deleted and re-worked every ERC error; it was very time consuming.
True, I just grabbed a representative area showing the problem. It happened not to include the bus. The issues also appear to be more widespread but that’s an area to start.
I did try renaming the nets but that doesn’t seem to be possible. So far the only option would appear to be to re-enter the schematic entirely which isn’t even close to being an option.
To be honest it’s extremely difficult to investigate this without the schematic file, especially if this really is a bug. It could be anything, anywhere, and now we don’t even know if we can replicate the problematic situation.
If this a bug, you should report it, but it doesn’t help without the file. You can also strip down the file to minimum until only the problem is there, or try to create a new showcase from scratch.
Indeed. A few screenshots showing some highlighted names is not very useful here. In KiCad it’s legal to connect different labels together, and this is a useful feature. From your screenshots we can not see what else happens in the schematic. Normally it does give a warning about this in ERC, but those can be disabled. What does it say in your project about this?
I was presenting the images as a partial indication of the corruption not as the means to diagnosis. I wasn’t about to send a file to anyone without them being willing and able to dig into that corruption. That would be unfair to all
The second image comes from simply loading the file into rev 6, no editing. I was expecting and hoping corruption on this scale would have been seen before and that there was a fix or conversion process since 6 has been out for a while.
The images show the result of that. The labels are indications of the expected form and the signals originally given to those lines. Loaded into version 5 each line highlights on it’s own with the proper signal/net name. Loading into version 6 and it scrambles. Most of the nets are at a minimum renamed.
As far as ERC, this is what I get in that region, complaints about unconnected labels.
Not only are they connected, but reconnecting them has no affect. In any case that’s secondary to the nets being joined to a single net when the file was read in.
As far as reducing the size, that could be a long process with editing the file in rev 5 and eliminating unrelated errors from editing and then reloading into rev 6 to get the smallest the project size. While I understand the instinct, I do think the appropriate size in this case is the project given the extent of the corruption.
BTW, as far as reporting a bug I don’t have a gitlab account, which seems to be needed, and I really don’t need yet another account. I’ll do it I have to but it’s really more sand in the gears
There was a bug in V6.0.9. Updating to V6.0.10 should fix it.
And now there is also:
Updates in the 3rd number are bug fixes and minor things and an upgrade is always recommended and should be safe. Sometimes *&^%$#@! happens though, and if your ability to buy sandwitches depends on KiCad, then I recommend to wait about a week before you update. If a big blunder has been made, it should have been discovered by then.
Just a general note. Attaching a zipped project file isn’t unfair to anyone, except when the poster doesn’t have permission (by copyright or from employer etc.) to publish it. There are people here who are willing to test projects, sometimes someone may file a bug report for you if you are lucky, or even a KiCad developer may get interested and fix it (although usually an official report is needed).
Indeed. Sometimes I ask to upload a project, but if a zipped project is already attached then the incentive to have a look at what is going on without having to ask for it just lowers the threshold to have a look. And it’s not like you’re forcing anyone to look at your project.
OK, bopped a couple of alligators on the nose, downloaded the new version and gave it a try.
It made a significant difference and reduces the ERC errors to 68 (more than an order of magnitude reduction).
It’s either made clear something with buses or is complaining about something new.
It hasn’t fixed the issue I started with but the bus issue could be related and it’s clear enough that I’m going to try to reproduce it in something small enough to digest.
OK, I have managed to reproduce this in a nice small schematic using only standard library items. It is related to the busing. It’s definitely a behaviour change between 5 and 6 and I’d consider it a bug.
Note the highlighted net is composed of nets that remain separate in version 5. They are shorted on reading into version 6. I suspect the problem is that version 6 is interpreting the sub buses that are dropped off of the main bus as if they are the full bus. This is contrary to version 5 which correctly interprets them as subsets. It’s also, in my opinion, contrary to the principle of least astonishment. I would have expected it to work as it does in version 5.
The example I’ve done showing the issue sort of illustrates why it’s useful to behave in that fashion, but you can hopefully see why it’s useful for fanning out or merging signal buses. An example might be merging analog input signals to a central, high channel count converter, where each input channel requires significant conditioning and power management.
I think this likely accounts for most of the remaining issues since this particular schematic has multiple such buses with subset branches.
According to the documentation there should be a “migrate buses”-dialog at opening the v5-schematic, but this dialog didn’t show up. Thats the only bug I could see.
So for your schematic there is the need to differently slice the buses. (Or feed the complete bus into the subsheets).
Your sub-buses on the right side are not connected to anything. You can see that from the small square at the end. You need a subsheet entry and connect correctly.
Get that fixed first.
@mf_ibfeew well, that explains it. It’s decidedly unsatisfying to have that subsetting and supersetting capability suddenly disappear, it’s a very useful feature not to burden hierarchical sheets with knowledge of bus members it doesn’t use. Even more unsettling to have it fail silently on an upgrade.
This has the potential to produce boards with shorts, especially since it produces no errors on an ERC.
