Could not flush host TX2 fifo

Hi all,

I’m having difficulty with my Beaglebone Black while trying to control a HackRF. The issue only ever comes up if I try to transmit something, which makes sense since it seems to be trying to flush the TX buffer.

The device is connected to a powered USB hub, and works just fine from my desktop and laptop. I don’t have another embedded device that I can try it on.

I’ve seen some other posts about the same error, but I haven’t found anything helpful or explanatory. Here’s a post someone else made with the same issue, using a BladeRF. I’ve seen it pop up for other devices too, but I’m not getting anywhere close to finding a solution.

Below is what dmesg is printing. It happens consistently any time that I try to transmit, and the entire bus seems to be dead once it happens (my WiFi dongle stops working too until I reboot). Does anyone have any insight or suggestions? This is a complete show-stopper for my project, in which I’d be using the HackRF to do some transmitting.

First, which distro are you using, and how old is the Linux image ? The reason why I ask is that this problem is similar to several posts on this group dating back to 2013 . . .

If you check this out, around line 127 seems to be where the error is issued.

http://lxr.free-electrons.com/source/drivers/usb/musb/musb_host.c

I’m using Arch Linux with all packages updated (kernel 4.2.0-1-ARCH). I noticed the older posts as well, but I haven’t seen anyone offer a solution. My guess is that the problem was just never resolved.

You may want to setup and use, at least temporarily a Debian sdcard, and see if you can reproduce the error.

With that said, I bet if you’re able to disable OTG USB, the problem will go away.

They have pio mode set too..

https://github.com/archlinuxarm/PKGBUILDs/blob/master/core/linux-am33x/config#L4133-L4134

ARCH arm, sync's with our patchset, so it's almost exactly the same as
linux-image-4.2.0-bone2 in our debian repo..

Regards,

They have pio mode set too…

https://github.com/archlinuxarm/PKGBUILDs/blob/master/core/linux-am33x/config#L4133-L4134

ARCH arm, sync’s with our patchset, so it’s almost exactly the same as
linux-image-4.2.0-bone2 in our debian repo…

Regards,

Ok, so trying a Debian image probably would not solve the problem then. However, I’m curious if disabling OTG on USB will fix it. Assuming the device Stephen is using does not require OTG USB . . .

Thanks, I’ll try disabling it. Is there a way to do it without a kernel recompile?

-Stephen

I just checked out the code to attempt a build, and it looks like the kernel config already has CONFIG_USB_OTG disabled, unless I’m looking at the wrong configuration file somehow.

-Stephen

I just noticed that on my image too . .

william@xanbustester:~$ zcat /proc/config.gz | grep OTG

CONFIG_USB_OTG is not set

CONFIG_USB_OTG_WHITELIST is not set

CONFIG_USB_OTG_BLACKLIST_HUB is not set

CONFIG_USB_OTG_FSM is not set

CONFIG_USB_FOTG210_HCD is not set

CONFIG_USB_FOTG210_UDC is not set

Although I do recall someone posting a month or two ago in relation to the auto kernel reboots, how to disable the OTG USB stuff. I think it was a kernel level fix.

Here is the post I was talking about: https://groups.google.com/forum/#!searchin/beagleboard/reboot|sort:relevance/beagleboard/2yOpE3XYJ1Y/gXB5oSuM7VAJ

lisarden’s 4th or 5th post, he talks about modifying board-am335xevm.c.

Anyway Im not sure this will fix anything. It is only a gut feeling I get when reading all the posts on the internet, and the “host” part of the error message. That you, and others are getting. I’ve been reading about a lot of musb host mode errors over the lat 2-3 years . . .

Well thanks for the help, but I guess that I’m going to have to use some other hardware for this project. Based on all of the other (unresolved) posts going back years, it seems the BBB just doesn’t have stable USB support.

A few posts below the one you’re referring to, they just disable the kernel config option instead. It looks like it didn’t really help anyway, and the only thing that worked was to power the board via USB instead of barrel plug, but then you can only get 500ma.

A few posts below the one you’re referring to, they just disable the kernel config option instead. It looks like it didn’t really help anyway, and the only thing that worked was to power the board via USB instead of barrel plug, but then you can only get 500ma.

Well, no. It puts the USB into peripheral mode, instead of being in OTG host mode. As for 500ma . . that’s all you’re going to get anyway, so maybe that is your problem.

Anyway, the idea was to get the USB port out of host mode. Still not sure it would work, but I’m starting to wonder now if your problem is power related. As in power provided to you hackRF. Personally, I think it is a bit ridiculous that such a great piece of hardware is only power-able via USB ?!

What do you mean? I’m giving the board 2.5A via a wall plug. If I power the board over USB, then I can only give it 500ma.

Also, short term, using something else to get your project working would probably be a good idea. However, it’d be cool to get that problem resolved eventually too . . .

Also, like I said in my first post, the HackRF is connected to a powered USB hub. It should be getting plenty of power.

My project is already working on a desktop, but the whole point was to make it a small portable device.

What a minute. Which port are you using to attempt to connect to your hackRF ? the mini, or full sized port ?

The full sized. Why would I use the mini? I’d have to get an adapter, but I could try it I guess. I have a powered USB hub connected to the full sized USB port. Then a HackRF connected to the hub.

No, just making sure you were not using the mini - heh.

Anyway, I do not really know where to start in fixing this, well actually I do. . . libusb, but after that . . . no idea.

Hubs can also sometimes cause problems, but you’re already able to receive it seems. Which I guess as long as you’re not trying receive and send at the same time. You’re good.

Ah, I see. I’ve tried it with and without the hub. I actually bought the hub because I at first assumed that the HackRF wasn’t getting enough power, but I saw the same behavior.

I might try a raspberry pi, but I’m kind of worried that it’ll use the same USB stack and have the same issue. Might be worth a shot though.