> The reason why the adapter locks up on the second try is that for some reason
> the first 4 bytes of the talk command (09 13 02 00) are not received by the
> xum1541 firmware. But the 2 data bytes (48 6f) are [...]
Do you have the possibility to check if the first bytes (09 13 02 00)
are not received, OR if they are handled by the previous command? That
is, is it possible that for some reason, the firmware believes the
previous command has not finished yet and handles these bytes as being
part of the previous command?
Are you using a SparkFun Pro Micro setup? I have one here, too, and I am
currently thinking how I can create a setup so I can see the console
debugging output.
> Are you using a SparkFun Pro Micro setup? I have one here, too, and I am
> currently thinking how I can create a setup so I can see the console
> debugging output.
>
> I use a cheap pro micro from aliexpress. I don't know if it differs from the
> sparkfun version. But if it doesn't it should be pretty easy for you to
> reproduce the problem. Doesn't your board lock up when you issue two "cbmctrl
> status" commands in a row?
No, I do not have this problem here!
That's the weird thing: I know that some people have this problem, but I
do not know what exactly triggers it.
Oh, are you on Windows or on Linux (or MacOS)? Are you using libusb1 or
libusb0? Are you using the latest git master?
> My plan is to go through the LUFA code and the atmega32u4 datasheet and try to
> understand what exactly happens in the "ConfigurationChanged" code.
Please note that the LUFA code is from 2009 (091223)! We did not update it since
then. The latest one seems to be 170418.
Trying to use a newer LUFA failed for me until now, because there have
some things been changed. It might be a better solution than to try to
debug this issue, if you believe that the problem might be in LUFA.
I tried to work on updating LUFA to the last version (170418). It can be
found on the branch lufa-170418 on github.
Unfortunately, after flashing it, the device does not answer anymore. So
I have a problem, and I do not know what it is at the moment. That's why
I did not add compiled HEX files, because I do not want people to brick
their device with it.
Can you show a diff of what you have done exactly?
> That's the weird thing: I know that some people have this problem, but I
> do not know what exactly triggers it.
[...]
> That's interesting. I thought the people that are not able to reproduce it are
> using different boards. I'm using git master from github on linux with libusb
> 1.0.23.
It does not seem to depend on the board. I even have had a report from
someone where an original ZoomFloppy never worked. She sent it to me, it
worked here on Windows and Linux, but when she got it back, it did not work
there.
That's weird, and we never found a solution to it.
> Are you by any chance on Windows?
I can test on Windows, but my main development machine is Linux, Debian
Buster at the moment.
> Because the comment for USB_ResetConfig()
> suggests that only linux and macos send multiple multiple "set configuration"
> messages. So if windows doesn't send them (because maybe it caches the last
> value and doesn't send the message if it hasn't change) it would be plausible
> that the problem isn't triggered there. If it otherwise works on windows it
> might also suggest that the usb reset in EVENT_USB_Device_ConfigurationChanged
> () isn't necessary at all.
I believe I have had more reports from Windows users than from Linux
users. This might be because more people are using Windows, though.
Can you just comment out USB_ResetConfig() (and leave everything else
as-it-is, without your patch!)
Does it solve your problem? Does it introduce any other problems you are
aware of?
As the BulkVendor example does not even use Endpoint_ResetEndpoint() (=
Endpoint_ResetFIFO(), as it is called in the older LUFA) and
Endpoint_ResetDataToggle(), nor Endpoint_IsStalled() or
Endpoint_ClearStall(), I suspect using them might be the problem in the
first place.
An endpoint can be reset at any time by setting in the UERST register the bit corresponding to the endpoint(EPRSTx). This resets:- the internal state machine on that endpoint- the Rx and Tx banks are cleared and their internal pointers are restored- the UEINTX, UESTA0X and UESTA1X are restored to their reset valueThe data toggle field remains unchanged.The other registers remain unchanged.The endpoint configuration remains active and the endpoint is still enabled.
2. So to work around that possible problem, it would be possible to only make the libusb_set_configuration() call if the device isn't already configured.
3. So I propose a simpler solution: What also works for me is disconfiguring the device in xum1541_close() by calling usb.set_configuration() with a configuration of -1.
There is one thing, though, that I stumbled upon
In xum1541/descriptor.c, we tell that the USB Version is 1.10
(VERSION_BCD(01.10) or VERSION_BCD(1, 1, 0) in LUFA-170418).
However, in the Makefile, we specify:
-DUSE_STATIC_OPTIONS="(USB_DEVICE_OPT_FULLSPEED | USB_OPT_REG_ENABLED | USB_OPT_AUTO_PLL)
So, we have FULLSPEED with USB 1.1 - which does not make sense. Can this
be a problem?
> The reason is that apparently the xhci_hcd driver (or libusb when using this
> driver, I'm not sure) does not reset its data toggles when a "set
> configuration" message is issued, while the ehci-pci driver does.
https://wiki.osdev.org/Universal_Serial_Bus#Data_Toggle_Synchronization
states:
Data toggle synchronization works differently depending on the type of transfer used:
* Control transfers initialize the endpoint's data toggle bits to 0 with a SETUP packet.
* Interrupt and Bulk endpoints initialize their data toggle bits to 0 upon any configuration event.
* Isochronous transfers do not perform a handshake and thus do not support data toggle synchronization.
* High-speed, high-bandwidth isochronous transfers do support data sequencing within a microframe.
The 2nd point seems to suggest that it should reset it, beause "set
configuration" should be "any configuration event", should'nt it?
So, I am happy that Martin has done his analysis, and it sounds
reasonable to me, although I cannot tell for sure at the moment. I
think, we should not shot the messenger because he uses an unsupported
device or setup, but try to understand his findings and look if we can
use it to improve the device, shouldn't we?
--
Given the low volume of posts on this list, the overarching nature of these issues, and the fact the discussion is already started, feel free to keep it here.
Jim
-- RETRO Innovations, Contemporary Gear for Classic Systems www.go4retro.com store.go4retro.com
But, I just found the following: A call to Endpoint_ResetDataToggle() in
USB_ResetConfig() of xum1541.c.
Does it make sense at that place? Should we be missing with the data
toggle at all?
> 3. So I propose a simpler solution: What also works for me is
> disconfiguring the device in xum1541_close() by calling
> usb.set_configuration() with a configuration of -1.
>
> https://github.com/thierer/OpenCBM/tree/deconfigure_device_on_close
This would be one possible way to do it. Another one might be to
disconfigure it immediately before configuring it, wouldn't it?
> There is one thing, though, that I stumbled upon
> In xum1541/descriptor.c, we tell that the USB Version is 1.10
> (VERSION_BCD(01.10) or VERSION_BCD(1, 1, 0) in LUFA-170418).
> However, in the Makefile, we specify:
> -DUSE_STATIC_OPTIONS="(USB_DEVICE_OPT_FULLSPEED | USB_OPT_REG_ENABLED |
> USB_OPT_AUTO_PLL)
> So, we have FULLSPEED with USB 1.1 - which does not make sense. Can this
> be a problem?
>
> Good catch. I don't know what the implications are, though. When I changed this
> to "VERSION_BCD(02.00)" "VERSION_BCD(03.10)" it still didn't work without one
> of my patches.
Not a good catch, full speed is already available in USB 1.1. It seems I
was a little bit confused. ;)
> https://github.com/thierer/OpenCBM/tree/deconfigure_device_on_close
>
> As already stated in my previous post, I think that 3. is the cleanest
> solution, but all 3 work for me on my linux system in the sense that "cbmctrl
> status" doesn't lock up on multiple, consecutive invocations, regardless if the
> promicro board is connected to a port that's handled by the xhci_hcd or the
> ehci-pci driver.
I merged this approach. I am currently building a 0.4.99.100 for
Windows, so people can test it there if they like. For Linux, the
sources are there.
--
You received this message because you are subscribed to the Google Groups "ZoomFloppy Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zoomfloppy-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/zoomfloppy-users/2e65c6f9-87b3-46db-82fa-07b8b7bd40a1o%40googlegroups.com.
Even more weird: I just re-realized that
opencbm/lib/plugin/xum1541/xum1541.c has some hard-coded exit(-1) in it!
If I stop rpm1541, for example, the cbm_reset() fails and the command
ends because of this exit command! Thus, the driver is never closed (cf.
function reset() in opencbm/demo/rpm1541/rpm1541.c.) - the ZF flashes in
fast succession, and the next command fails. That's similar to what you
are experiencing, right?
If I replace these exit(-1) with return -1, then the problem goes away.
Could it be that we have a similar issue with cbmctrl, which is
prematurely ended because of the libusb_set_configuration() trying to
set configuration 0, resulting in the flashing of the devices some
people report?
Can it also be a part of the problem with the data toggle, because the
USB device is not correctly taken down / closed?
Before a USB device’s function may be used, the device must be configured. From the device’sperspective, configuration involves correctly processing a SetConfiguration() request with a non-zeroconfiguration value. Configuring a device or changing an alternate setting causes all of the status andconfiguration values associated with endpoints in the affected interfaces to be set to their default values.This includes setting the data toggle of any endpoint using data toggles to the value DATA0.
> I don't understand your example with rpm1541.c: From a quick glance (I never
> saw or used that program) it does seem to close the device before calling exit
> ()?
But the library calls exit() because the taking down failed.
Also very interesting is the warning here:
https://www.kernel.org/doc/Documentation/driver-api/usb.rst:
USBDEVFS_SETCONFIGURATION
Issues the :c:func:`usb_set_configuration()` call for the
device. The parameter is an integer holding the number of a
configuration (bConfigurationValue from descriptor). File
modification time is not updated by this request.
**Warning**
*Avoid using this call* until some usbcore bugs get fixed, since
it does not fully synchronize device, interface, and driver (not
just usbfs) state.
If I take this warning seriously, the approach (GetConfiguration to test
if we are already configured the right way, and SetConfiguration only if
not) starts looking better to me. Perhaps, this is the better way, and
everything else we are just doing is just too much work for no benefit!
So, this patch
https://github.com/thierer/OpenCBM/commit/88f2a705a6152fa7f92c8fd197085660b373cc16#diff-4daf10310be7ed8344d882a79444d1dc
might be the best one instead of variant 3.
The only change I would do: Instead of testing if config == 0 (line
564), I would test for config != 1.
But, if we take the current approach, then the following applies:
> But that's not what's happening with the set_configuration call in xum1541_init
> (). Here the device is already configured and we're sending a message
> requesting the device to select the one and only configuration it has and that
> it is already in. That isn't the same for me. It might still be true that it
> should, but my problem here is that people write a lot of stuff on the
> internet, that's not necessarily true, so I don't always trust random guys
> posting things...
neither the linux kernel nor the xum1541 have a look if we are comming
from the unconfigured state and are getting configured: The
SetConfiguration always results in clearing the data toggle!
Linux Kernel:
https://docs.huihoo.com/doxygen/linux/kernel/3.7/drivers_2usb_2core_2message_8c_source.html#l01706
You can see that it is not even interested in the previous
configuration, it always executes the same commands.
I looked at the linux kernel before, and I don't really understand what's going on. Plus, this is from the 3.7 kernel, which was released in 2012. Who knows what the code looks like today. The file has some interesting information, though. It does seem to reset the data toggles in the usb_set_interface() function. I noticed that the avrusb code you linked to did that, too. Maybe that would be a way to reliably reset the data toggles on linux. It refers to the same section 9.1.1.5 of the usb specs as the post on the libusb mailing list, that also only says about "changing an alternate setting" which I think doesn't necessarily apply to selecting the same setting again, but I'll try and report back.
Do you want to create a PR?
>> Do you want to create a PR?
>
> I can do that (tomorrow), but I won't be able to test the windows part.
No problem, I can test it (in the VM, of course).
I wanted to ask because the last time I merged some change from you, you
told me that I should ask beforehand. ;)
If we are unsure about this, we can also make the change conditional and
let it in only on Linux. But for a start, I would like to include it in
all variants.
Do you want to create a PR?I can do that (tomorrow), but I won't be able to test the windows part.
I don't know what specific firmware 8 version is on my new ZoonFloppy, which I bought on eBay at the end of December 2021.
Hmmm, this seems odd. As far as I know, I'm the only source for ZoomFloppy units, and I do not offer products for sale on eBay. I wonder what device you have? Was it new? Is there a link or a pic?
There was a v8 beta at one point that had issues, so perhaps that was what was installed initially.
Not sure, just trying to nail down the details.
Jim
I mean all current opencbm versions starting from 0.4.99.100 till 0.4.99.103 showing the same Symptomes with the zoom floppy. xu1541 all opencbm versions from 0.4.99.99 till 0.4.99.103 works without issues (same hardware, same cables, same OS) .