It's not recommended to power Kasli and its EEMs through Stabilizer. That will likely overload and exceed specifications.
I've updated the Stabilizer book covering these things.

    rjo This is not how it is typically powered, I just noticed that it happens. I have both Kasli power supply and Stabilizer PoE connected.

      Yes. But did somebody test that?

      a month later

      Okay, I now only power it through the main Kasli power supply, but the problem with USB (No DFU capable USB device available) persists.

      • rjo replied to this.

        Please describe your system, computer, setup etc in more detail.

        12 days later

        iuriikor Is your issue resolved? If yes, could you comment for others to learn from?

            rjo Hi! Not yet, I got carried by another project and did not reply.

            Regarding the software we have a PC running on x64 Windows 10. I followed the setup manual from here: https://quartiq.de/stabilizer/setup.html. I have Mosquitto version 2.0.14 from here: https://mosquitto.org/download/, rustup version 1.57, cargo-binutils installed. I have just noticed that the network Sinara is connected to does not have a properly configured DHCP server, but this should not affect USB connection? I also do not know if the software that I have mentioned here is relevant to whether or not dfu-util recognizes the device. The version of dfu-util is 0.11.

            Regarding the hardware, Sinara is connected to a Netgear GS110TPv3 switch, which is connected to the lab PC with an Ethernet to USB adapter and is set to have a fixed IP address 10.34.16.99, and the IP address of Sinara is 10.34.16.100. Stabilizer is now powered from the main power supply that is plugged into Kasli. The ethernet port is disconnected since I only have PoE ports available on the switch, should be able to turn off though. In any case, the problem persisted with Stabilizer both connected and disconnected to the switch.

            Please let me know if there is any specific information you need so that I can be more useful in answering. Also, I see that I did not configure DHCP server and Mosquitto properly, but I do not know if this can lead to the fact that dfu-util does not see the device. Thank you.

              @iruiikor When I first tried flashing I encountered similar difficulty. My host is Linux. Are you using a USB data cable? Some cables are charge-only and are missing the data pins. In my case, I believe my cable may have not been properly seated in the Sinara panel. Here is a link about USB cables data-vs-charge

                melanieAQ Thanks for the suggestion! According to the datasheet it should be a data transfer cable

                • rjo replied to this.

                    iuriikor

                    • MQTT, DHCP etc all don't play any role until you have flashed firmware onto the device.
                    • To exclude the cable and USB port, please check that some other device works on that cable on that port
                    • Be super careful when removing or inserting the modules into the crate. Never ever run anything with the modules pulled out partly. You will short circuit sensitive electornics on the PCB underside.
                    • Check that the BOOT jumper is mounted.
                    • Which LEDs are lit on Stabilizer when you power it through Kasli?
                    • Check dfu-util --version and show me your USB device tree (screenshot) and dfu-util -l

                        rjo

                        • I swapped the cable for the one that surely works (tested with another device on the same port I'm using for Stabilizer), and I still get the same issue
                        • I always unplug all power cords before pulling Stabilizer out, so that part should be fine
                        • Boot jumper is mounted and connects the two pins properly, double checked that
                        • Only the ones on the PCB (N12V, P12V, P12VA, P5VA, etc. marked on the PCB); leds on the front panel have always been off. Only when PoE cable was connected, two leds around the ethernet port were blinking.
                        • The dfu-util version is 0.11, but I see no devices in the list. On the web page of dfu-util (http://dfu-util.sourceforge.net/) it says that the device must be registered with WinUSB driver, and then on the libusb wiki (https://github.com/libusb/libusb/wiki/Windows#How_to_use_libusb_on_Windows) it's recommended to use Zadig to do that, but in Zadig I also don't see Stabilizer.

                          Hmm. Other than an improper USB connection (do you have the impression that the USB connector is properly plugged in and latches?) I don't know. Possible routes to take from here: (a) try e.g. an Ubuntu USB boot on your computer, and show the dmesg -H after powering up the USB connected Stabilizer, (b) try SWD debugging and flashing to exclude some other breakage.

                            rjo Well, the port on the PC should be fine. I'll try to tinker with it a bit more, let's see where it gets me.

                              rjo While I wait for the debugger to arrive, I installed Ubuntu. The command you specified gives quite a bunch of output - is there any section you are particularly interested in, or should I just send all of it output?

                                Start dmesg -HW, then power stabilizer, and send what's printed.

                                8 days later

                                As embarrassing as it is to admit, the problem was in the jumper. I checked multiple times that it shorted the pins, but still when I changed it everything worked.

                                I now have another issue, with MQTT broker this time. Stabilizer is connected to the PC through a switch. The port used by the switch has a static IP address 10.34.16.99. I followed the manual in setting up the broker, and set Stabilizer to use static IP 10.34.16.101, which can be reached from the host PC. The broker IP address is set to 10.34.16.102. I added port 1883 to the exception list of firewall, and when I run netstat -anvp tcp I get a line TCP 0.0.0.0:1883 0.0.0.0:0 LISTENING, which I understand is a sign that broker was set up. However, when I run MQTT explorer and try to connect to 10.34.16.102:1883, I do not get any messages, and every once in a while a red sign saying Disconnected from server pops up in the bottom left corner.

                                The port used by the switch has a static IP address 10.34.16.99.

                                What does that mean? Ports on switches aren't assigned IPs. There should only be two IPs in this game, broker, and Stabilizer. With your IPs there can also not be a gateway between the two.

                                ... when I run MQTT explorer and try to connect to 10.34.16.102:1883, I do not get any messages, and every once in a while a red sign saying Disconnected from server pops up in the bottom left corner.

                                That would indicate there is no broker running on that address or that it's blocked by something. Get mqtt explorer connected to the broker first and then look at stabilizer again.

                                What does that mean? Ports on switches aren't assigned IPs. There should only be two IPs in this game, broker, and Stabilizer. With your IPs there can also not be a gateway between the two.

                                I mean in the settings of ethernet port to which the switch is connected I set static IP address 10.34.16.99.

                                That would indicate there is no broker running on that address or that it's blocked by something. Get mqtt explorer connected to the broker first and then look at stabilizer again.

                                Do I need to specify broker IP address at any step besides building the app? And what could potentially be blocking it?