niles Posted April 9 Report Posted April 9 Hi all, I'm finally at the point of 99% finished with my MB6582 build and have run into a "CAN Bus errors" issue. Here is a description of my build: 8 SID 8580 chips 4 PIC18F4685 burned by me using Pickit3 Using latest versions of boot loader, Mios OS, MIDIbox SID (v6582) available for download. I'm pretty sure it's not the PICs or software. What happened is I put master core 1 in, it works fine. Slave core 2 in, that works fine. Slave core 3 in, that works fine. Slave core4 in, I get CAN bus errors on SID2,3,4. I reburned PIC4 thinking that could work (read it on forums) and no luck. If I remove slave core3 and put slave core4 into the third spot, leaving fourth empty, then I do not get errors and just "SID3 not available". To me that means the core4 area on the PCB has some kind of issue but I can't figure out what to look for. I do not see any lifted tracks or cold joints. Are the CAN components just in the small area around the PIC socket? Maybe I'm missing a jumper or something stupid like that. Thank you PS In case any future folks read this, I originally burned my PICs years ago using Pickit3. I had a huge issue re-burning a PIC using the pickit3 since the easy standalone software I previously used is not supported anymore and Microship requires you to use this huge, unwieldy software called MPLAB X IDE/IPE which took like 30 mins to install and has a substantial learning curve. I found http://kair.us/projects/pickitminus/ It supports Pickit3 USB and worked fine. Quote
TK. Posted April 9 Report Posted April 9 Hi Niles, very good analysis so far, this helps to think about potential problems! CAN bus error means, that something is wrong with the CAN bus connections. E.g. the response from a slave core violates the CAN protocol, which indicates an electrical problem. Here the schematic: http://www.ucapps.de/midibox_sid/mbsid_v2_communication.pdf J15.D2 (=Pin RB2) and J15.D3 (=Pin RB3) are the CAN TX/RX pins What comes into my mind: the diode for core4 is soldered in the wrong direction, ensure that the cathode is connected with RB2 (like for the other PICs) or there is a short around pin RB2 Best Regards, Thorsten. P.S.: thanks also for the background information about PICkit- - I added it to the documentation! Quote
niles Posted April 10 Author Report Posted April 10 Thank you, Thorsten! Fingers crossed that one of those is the source of the issue. Quote
niles Posted April 10 Author Report Posted April 10 (edited) Would you mind confirming if my picture is correct concerning the locations of RB3, RB2, D3, D2? The diagram you provided looks like all D3's on the J15 headers would be tied together, but I'm not experiencing that, and I'm thinking either something different is happening on this board or I have the wrong locations. EDIT: Also wanted to add, in case it helps, that I am running the Newhaven OLED. On Core1 I soldered the little jumpers on the bottom side of the board under the core, but did not solder them in the other cores, would that be necessary? The OLED works fine when connected to core1, I think at some point I installed the custom LCD driver I found on the Newhaven OLED post on Core1 PIC. When I connect the display cable to any other J15 header I see nothing, so I guess they are missing the custom driver, and would need the tiny solder pads jumped, although that's not probably not needed to get the CAN bus error resolved. Edited April 10 by niles Quote
TK. Posted April 10 Report Posted April 10 Yes, I can confirm that RB2/3 are marked correctly. You can ignore D3/D2, because in distance to MBHP_CORE the RB2/3 pins are not connected to these datelines, but to different IO pins at J5 (that's also the reason why a special LCD driver is required when displays should run in 8bit mode) On this picture I can see that the diode is connected the right direction, so this is not the problem. However, you mentioned that you installed a custom LCD driver - which one exactly? The custom driver doesn't need to be installed on the other cores, and also jumpers are not required for these ones - only for the master core where the display is connected. Just to be doublecheck: if you swap core 3 and 4, do you get the "CAN bus error" message as well? This would confirm that it can only be an electrical issue. Best Regards, Thorsten. Quote
latigid on Posted April 10 Report Posted April 10 Is it anything to do with the device ID that was flashed? http://www.ucapps.de/mios_bootstrap_experts.html Quote
niles Posted April 10 Author Report Posted April 10 3 hours ago, TK. said: However, you mentioned that you installed a custom LCD driver - which one exactly? It was mentioned in the newhaven OLED post and it was called device_id_00_lcd7.hex. I don't remember exactly where I got it in the forums but it wasn't posted in that thread. The OLED ended up working fine with it - I only sent it to the master core via MIOS Studio. If I swap 3 and 4 then I get the CAN bus errors. means it's some type of physical connection issue? Could it be around core3 since that is just upstream of 4? Quote
niles Posted April 10 Author Report Posted April 10 2 hours ago, latigid on said: Is it anything to do with the device ID that was flashed? http://www.ucapps.de/mios_bootstrap_experts.html Hi - I doubt it, I used the PICKIT3 to erase PIC4, re-wrote the boot loader, put it in core1 place and sent the MIOS OS, then the device 03 hex file. MIOS Studio would only recognize it as "3" from that point on. Quote
TK. Posted April 11 Report Posted April 11 6 hours ago, niles said: If I swap 3 and 4 then I get the CAN bus errors. means it's some type of physical connection issue? Could it be around core3 since that is just upstream of 4? Yes, very likely a connection issue. The CAN bus is a single wire bus, all RX pins are connected together, and TX pin drives the wire via a diode. Do you have a multimeter with continuity & diode tester ("beeper")? Then: pull out all PICs, check for continuity between all RB3 pins in both directions. Then check that continuity between RB2 and RB3 pins is only in one direction: if Minus is connected to RB2 and Plus to RB3 it should be "beep", if Minus is connected to RB3 and Plus to RB2 it should not "beep". Best Regards, Thorsten. Quote
niles Posted April 11 Author Report Posted April 11 Thanks again for your help, Thorsten. I did all the tests and everything passed. I get a diode beep only in the correct direction between RB2 and RB3, nothing in the opposite direction. All RB3s are connected, no shorts between RB2 and RB3 on all sockets. I'm not sure what else it could be connection wise...the circuit seems OK. You mentioned pulling the PICs first to test, which I did, would it damage a PIC to run a diode test with it in place? I'm wondering if somehow physically inserting the PIC into the socket in core4 could be the issue? Could there be a voltage drop if all 4 PICs are inserted or something...just grasping at ideas now. I'm using Power option E since that seemed the most modern and reliable. Quote
latigid on Posted April 11 Report Posted April 11 On 4/9/2025 at 4:01 PM, niles said: If I remove slave core3 and put slave core4 into the third spot, leaving fourth empty, then I do not get errors and just "SID3 not available". To me that means the core4 area on the PCB has some kind of issue but I can't figure out what to look for. I do not see any lifted tracks or cold joints. Are the CAN components just in the small area around the PIC socket? Maybe I'm missing a jumper or something stupid like that. How about if you put core 3 (or 4) into the fourth spot and leave the third spot empty? If it fails then you know that the fourth spot on the PCB has a problem. Measure conductivity from the pin of the socketed chip to somewhere else on the PCB, it could be that the socket itself does not connect the pin to the PCB. Quote
niles Posted April 11 Author Report Posted April 11 2 hours ago, latigid on said: How about if you put core 3 (or 4) into the fourth spot and leave the third spot empty? If it fails then you know that the fourth spot on the PCB has a problem. Measure conductivity from the pin of the socketed chip to somewhere else on the PCB, it could be that the socket itself does not connect the pin to the PCB. Good idea. Here's what I tested and the results are super strange: I didn't do all possible combinations but hopefully this helps, table below of what I see near the SID select buttons. If there's a *, that is saying "SIDx Not Available (No MBNet Response)". If I select a SID slot with a "-" then I can modify the respective parameters like normal, so I assume that means A-OK when there's a "-". # Core 1 location Core 2 location Core 3 location Core 4 location Display with Sid 1 active 1 PIC 0 PIC1 PIC2 PIC3 1 * * * (CAN BUS ERRORS) 2 PIC 0 Empty PIC2 PIC3 1 * - - 3 PIC 0 Empty Empty PIC3 1 * * - 4 PIC 0 Empty PIC3 Empty 1 * * - 5 PIC 0 Empty PIC3 PIC1 1 - * - I seem to be getting the CAN Bus error only when there are all four, in whatever order. Something with the master core? Quote
TK. Posted April 11 Report Posted April 11 Interesting, this gives a different picture! No, the problem shouldn't be related to any core. The master can communicate with slave cores (which means: a lot of things are working fine!), but the entire communication breaks down once 4 cores are connected to the CAN bus. Two new ideas what could go wrong: power consumption: does it work if you pull out the SID chips? If you still see the same problems, the PSU is fine another potential problem could be that the 1k pull-up resistor isn't connected properly to the CAN wire. Without PICs in the socket you should measure 1k ohm between all RB3 pins and a +5V track Best Regards, Thorsten. Quote
niles Posted April 11 Author Report Posted April 11 I pulled all the SID chips very carefully and still saw the issue, so PSU is fine presumably. Confirmed when I then pulled the PICs and saw 10k ohms across RB3 and Pins 11,32 of the socket and J5-Vd. Someone put a 10k for R80 instead of 1k, annoyingly... :P I replaced R80 with 1k and we have success! I guess that makes sense that the issue only manifested when all four were added. Can't thank you guys enough. I really appreciate it as always! I'll be making a separate thread eventually once I get my front panel finished. Cheers! Quote
TK. Posted April 11 Report Posted April 11 Hurray! Yes, this totally makes sense - an unexpected error with plausible effects: than weaker the pull-up & than more PICs are connected, than more likely unstable CAN communication Best Regards, Thorsten. Quote
latigid on Posted April 12 Report Posted April 12 Congrats, really glad that you got it working! Really it was TK. who had the magic touch here, still after 2+ decades of building these things. :) Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.