Ok great, I believe that communication with the DieBieMS is the source of the freezing you are seeing. CAN forwarded messages have proved to be challenging for the uSplit to handle in the past. Since this is a communication scheme that I have not been able to test (I do not have a DieBieMS), it is very likely there is a unique transfer happening that causes the uSplit to enter an invalid state.
Do you have a logic analyzer?
Can you try removing the DieBieMS to see if the communication still fails?
I have just posted a new FW (v0.9) for the uSplit to my site This FW update should improve general stability and remove any inconsistencies in communication on the DEV ports. There should no long be the situation where a device combination works when connected to one set of DEV ports and not another set.
There are still a couple bugs that I know of and need work out, but I wanted to share the latest stable version in the meantime. The bugs I know dont show up except for when multiple packets overlap in a particular way and my only way of getting that to happen is by letting it sit and run for anywhere from 15 to 45 minutes, so testing going real slow
I’ve updated the steps to try making this a bit clearer. The uSplit gets power from the ESC and only uses the USB cable for data transfer. To turn the uSplit on/off you need to turn the ESC on/ff. So you will need to turn you board off and on again.
I currently have 13 soldered up and ready to be sold, but those have been committed to a European group buy that @MauveMaverick is putting together. Currently 7 of those are spoken for and the deadline for the group buy is June 1st. If any remain unclaimed at that point, I will post the rest to my site.