XHC WHB04B development?

I don't think I would trust a USB device under these circumstances. I would recommend you go back to XHC's website and look for a 433 MHz pendant that hard wires in to send/receive unit. After years  of use, these have never let me down 

Do you have a link to the one you use or a model number?

I had a feeling that it could be possible to read out the factory firmware from the dongle due to some bugs in the firmware. And that is indeed the case, at least for a partial readout. It is possible to read the firmware from where the USB device descriptor is stored in program memory until and including the bootloader. I added this tool to the github repository:
github.com/finngineering/whb04b/blob/mas...s/firmware_readout.c
While I think this tool should be safe to use, I give no guarantees. With a partial readout, I could compare that to my firmware, and if it matches, the likelihood that the whole firmware is the same is very high.

Actually, now that I've done this, I remember that there is a much easier way to read out the firmware from CH55x with bootloader version lower than 2.50 (which is the version that my dongle has). The above tool should print the bootloader version, and if it's less than 2.50, I could maybe make a tool to read out the firmware through the bootloader and over USB.

Here is what happens when I run the tool. My whb04b is from the era when they just stopped selling the predecessor. The output from the command is attached,

Thank you for testing. The output indicate that the program was working as expected. The firmware is not exactly the same as mine, but it looks similar. How big differences/similarities there are would require disassembly comparing those. I can see that at least memory addresses are a bit different. Here is the output from mine (not the real dongle, I put the factory firmware on another device which has bootloader version 2.40): The addresses and sizes are close to each other, but not exactly the same.

Because you have bootloader version 2.40, I believe we would be able to read out the firmware through the bootloader. But it requires creating a similar program for that as the one we just used. And to get to bootloader mode, a 10k resistor needs to be added to the pendant. So maybe better to wait until I have tested the new firmware a bit more. And then you could read out the firmware and flash the new one at the same time, if you are still interested at that point.

I used the mill for a couple of hours today with my firmware in the pendant. I tried my best to cause some issues, but no disconnects from the dongle nor any other issues as far as I could tell. To be honest, I'm surprised that it works this well already.

I found a sticker with version information on the back on my pendant (underneath the rubber):
 
The top row is the firmware version and the bottom row the hardware version, I believe. And the RX should be the dongle, because there is a V09 marking on the main board (underneath the RF module).

And I attach a couple of photos from the dongle as well, in case somebody wants to compare. Not the best photos. I took them through the microscope some months ago. And right now I have a thousand wires connected for debugging, so not possible to take good photos at the moment.
 
 

The sticker on my pendant 
 

Had two crashes yesterday. Mode switching. libusb_fill_interrupt_transfer() isn't the solution.
 
I had commented out the assert() in setupAsyncTransfer and let it continue
Failed here  github.com/LinuxCNC/linuxcnc/blob/0673e3...whb04b-6/usb.cc#L541





 

Okay. I did not really think that libusb_fill_interrupt_transfer() would solve the issue. But that IS the correct function to use in any case.

If the disconnect happens only at mode switches, I'm pretty sure it can be solved simply by modifying the xhc-whb04b-6 component. Maybe we need to add some more (temporary) logging to the component to pinpoint the issue.

It appears our dongle firmware is different by one version increment. But of course the hardware side is the important one for compatibility. I would think that there is a good chance that the hardware is compatible or the same.

I have added a bit more logging to the component..
The component is attempting to connect, it says, but I wonder if it actually tries and why that doesn't work.

Do you mean that the pendant did not recover in the above situation after you had commented out the assert line?

You could enable all logging by adding the "-a" option when loading the xhc-whb04b-6 component. It will write a lot of things to the terminal... which makes it easier to figure out if it gets stuck in some specific part of the code.

@Hakan:
Strange. Mine doesn't show anything. But it's an LHB04B-6 TX V3 (Wired version)
As much as I read, it should work the same, but might be not.

Starting with -Ha and commenting out github.com/LinuxCNC/linuxcnc/blob/master...whb04b-6/usb.cc#L209 it shows:

out 0x06fefdfe801800bc 060e0800161e0200 06008069006e0000
out size 24B hdr 0xfdfe dom 0xfe status 0x80 coord1 +0024.3772 coord2 +0008.7702 coord3 -0002.0000 feed 0105 spindle feed rate 00110

So it seams the values are sent. Might be my device has a different firmware. With Mach3, I tried already and I didn't see any value. I will try again with Mach4.