XHC WHB04B development?
- kello711
-
- Offline
- Junior Member
-
- Posts: 25
- Thank you received: 0
Do you have a link to the one you use or a model number?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
Please Log in or Create an account to join the conversation.
- Finngineering
- Offline
- Premium Member
-
- Posts: 110
- Thank you received: 49
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.
Please Log in or Create an account to join the conversation.
- Hakan
- Away
- Platinum Member
-
- Posts: 1300
- Thank you received: 447
debian@dev100:~/src/whb04b/tools$ LD_LIBRARY_PATH=/usr/local/lib ./firmware_readout a.bin
1771927787.762 info: Read device descriptor with idVendor=0x10ce and idProduct=0xeb93
1771927787.763 info: Starting firmware readout process
1771927787.872 info: Read 5440 of 65535 bytes = 0.08%
1771927787.872 info: Found bootloader version 2.40 device descriptor after 5421 bytes
1771927787.872 info: Based on bootloader address, read firmware is from address 0x2961 to 0x37ff
1771927787.872 info: Wrote 5440 bytes to file a.binPlease Log in or Create an account to join the conversation.
- Finngineering
- Offline
- Premium Member
-
- Posts: 110
- Thank you received: 49
$ ./firmware_readout firmware.bin
1771943478.782 info: Read device descriptor with idVendor=0x10ce and idProduct=0xeb93
1771943478.783 info: Starting firmware readout process
1771943480.843 info: Read 5496 of 65535 bytes = 0.08%
1771943480.846 info: Found bootloader version 2.40 device descriptor after 5481 bytes
1771943480.846 info: Based on bootloader address, read firmware is from address 0x2925 to 0x37ff
1771943480.846 info: Wrote 5496 bytes to file firmware.binBecause 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.
Please Log in or Create an account to join the conversation.
- Finngineering
- Offline
- Premium Member
-
- Posts: 110
- Thank you received: 49
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.
Attachments:
Please Log in or Create an account to join the conversation.
- Hakan
- Away
- Platinum Member
-
- Posts: 1300
- Thank you received: 447
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
Attachments:
Please Log in or Create an account to join the conversation.
- Finngineering
- Offline
- Premium Member
-
- Posts: 110
- Thank you received: 49
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.
Please Log in or Create an account to join the conversation.
- Hakan
- Away
- Platinum Member
-
- Posts: 1300
- Thank you received: 447
The component is attempting to connect, it says, but I wonder if it actually tries and why that doesn't work.
Please Log in or Create an account to join the conversation.
- Finngineering
- Offline
- Premium Member
-
- Posts: 110
- Thank you received: 49
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.
Please Log in or Create an account to join the conversation.
- Hannes
- Offline
- New Member
-
- Posts: 14
- Thank you received: 6
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.
Please Log in or Create an account to join the conversation.