Trying to troubleshoot a main board with Rockchip RK3288 microprocessor

[Yamin]

Hi there everybody,
Sometime back I received a faulty guitar effects pedal board, it quite famous among the guitarist apparently. The unit does not boot up, goes through a start up sequence and just turns off. The main board is made up of Rockchip RK3288. Doing an internet search showed that a lot of people was going though the same situation. Nothing seems to get the unit to start back up - resetting etc.
The manufacture seems to not acknowledge this known issue and weren't very helpful. However I was able to source a spare board from the party which manufactures the main board.
Installing the new board rectified the problem, but after about three weeks the same thing happened. This time I was able to get it back to life by pressing the reset button, after couple of months it strikes again. This time however I was not able to get it back to life with the reset button. The guitarist it not really interested in reviving it anymore. So I thought I will just mess with just for my personal reference.
So as I said the microprocessor used Rockchip RK3288, the power management IC used is the ACT8846. I tried to find any obviously faulty components, couldn't find it. Going through the datasheet for the ACT8846 I found out that there was a way to manually reset the processor by shorting nPBIN to ground. I tried this but no difference. Start up sequence seems to work I even get 5V at the PWRHLD pin for a moment and it goes back to 0V. The nPBSTAT is used to fire an interrupt and it seems to be doing that as well. But the power doesn't latch. The button used to turn on the unit is one of those momentary push buttons which I assume fires some kind of an interrupt. If I press and hold this button, the voltage tends to remain at the pins for as long as I hold it.
I am quite new to troubleshooting circuits including microprocessors. Not having the schematic makes it that much harder. Just trying to 'solidly' figure out what the issue could be, even though I am not able to fix it. Any tips/help troubleshooting this would be greatly appreciated.
At this moment I am using the old mainboard with nothing else attached (buttons etc) only the 12V power supply.


Rockchip RK3288 datasheet -

http://webcache.googleusercontent.com/search?q=cache:http://opensource.rock-chips.com/images/4/4e/Rockchip_RK3288_Datasheet_V2.2-20170301.pdf

[coromonadalix]

Check the battery cell, on a different system with a dead battery it simply refused to boot

my 2 cents.


Is it booting thru an sd card ?  maybe the card is corrupted,  i have a board with an imx25 cpu with an winCE 6.0 OS   who did that symptom, the card had too many read and writes cycles ...  changed it for an sandisk brand  it was a kingston before, everything is now fine.

[Yamin]

I did check the battery it seems to have charge.

There is no SD card, I had a similar case with another effects pedal where the SD card contact was a bit tarnished. I cleaned it and it started working.

Any suggestion on  reading materials for troubleshooting microprocessor circuitry?

Thanks so much for your help.

[fzabkar]

I would measure the output voltages of each of the switchmode supplies and LDO regulators.

Given the symptoms, I'm wondering whether there is something wrong with the power-up sequence. The PMIC is programmed to power up each supply in a predefined order, so I'm thinking that the uP might get hung up if each supply doesn't come up at the right time.

[rsjsouza]

If this product is running embedded Linux and it is powered on and off with a mechanical switch, there is a chance the filesystem is getting corrupt (if it is poorly designed). I have seen this in certain products.

[Yamin]

I would measure the output voltages of each of the switchmode supplies and LDO regulators.

Given the symptoms, I'm wondering whether there is something wrong with the power-up sequence. The PMIC is programmed to power up each supply in a predefined order, so I'm thinking that the uP might get hung up if each supply doesn't come up at the right time.

Probably a very newbie question, but what is LDO? I came across that on the datasheet as well.

Make sense with the point you made about the power up sequence - would there be any way to know what the power up sequence should be or is it only known for the manufactures?

[Yamin]

If this product is running embedded Linux and it is powered on and off with a mechanical switch, there is a chance the filesystem is getting corrupt (if it is poorly designed). I have seen this in certain products.

This was my thought as well, and that's what a lot of people are speculating for this particular unit. However would there be any way to conclusively find whether that is the problem.

[rsjsouza]

If this product is running embedded Linux and it is powered on and off with a mechanical switch, there is a chance the filesystem is getting corrupt (if it is poorly designed). I have seen this in certain products.

This was my thought as well, and that's what a lot of people are speculating for this particular unit. However would there be any way to conclusively find whether that is the problem.

In this case, I would try to find three pins that would correspond to a UART port (maybe marked on the silk as TX, RX and GND) and connect a serial cable to a terminal program on a computer, configuring it to 115200 baud, 8 bits, no parity, 1 stop bit and no handshake (these are the most common settings for such ports in the marketplace).

Turning on the equipment, you should see a MLO/U-boot prompt, which will follow a sequence of operations with diagnostic messages.

If they have this filesystem indeed in flash, they should have furnished the board with enough RAM to hold the filesystem there. U-boot allows uncompressing the kernel and filesystem to RAM, which has the benefit that any corruption caused by the mechanical on/off would be simply vanished.

Another issue I have seen is the simple corruption of an ailing Flash device. This can be caused by either the processor itself (I have seen earlier Linux-based processors have bad NAND or NOR Flash controllers) or the Flash IC itself (either a  ad devices or simply second-hand ones in the most inescrupulous manufacturers).

[Haenk]

In this case, I would try to find three pins that would correspond to a UART port (maybe marked on the silk as TX, RX and GND) and connect a serial cable to a terminal program on a computer, configuring it to 115200 baud, 8 bits, no parity, 1 stop bit and no handshake (these are the most common settings for such ports in the marketplace).

There *is* a debug port, even noted as such and Comes with a header - even though it has four pins, that might be the way to go, probably just one pin not connected...

[rsjsouza]

In this case, I would try to find three pins that would correspond to a UART port (maybe marked on the silk as TX, RX and GND) and connect a serial cable to a terminal program on a computer, configuring it to 115200 baud, 8 bits, no parity, 1 stop bit and no handshake (these are the most common settings for such ports in the marketplace).

There *is* a debug port, even noted as such and Comes with a header - even though it has four pins, that might be the way to go, probably just one pin not connected...

Yeah, I just saw that on the photograph. Although four pins could also be JTAG (TCK, TDI, TDO, TMS, with GND being somewhere else). Check the connections with a continuity tester.

[coromonadalix]

In this case, I would try to find three pins that would correspond to a UART port (maybe marked on the silk as TX, RX and GND) and connect a serial cable to a terminal program on a computer, configuring it to 115200 baud, 8 bits, no parity, 1 stop bit and no handshake (these are the most common settings for such ports in the marketplace).

There *is* a debug port, even noted as such and Comes with a header - even though it has four pins, that might be the way to go, probably just one pin not connected...

And the 5 pins white connector near the 4 pins header ??
Yeah, I just saw that on the photograph. Although four pins could also be JTAG (TCK, TDI, TDO, TMS, with GND being somewhere else). Check the connections with a continuity tester.

Could be an serial or jtag port, as written  check for a ground pin and an 5v or 3.3vdc  pin .... and do a continuity check to the voltages regulators  once you find the main ones ...

And the 5 pins white header near the 4 pins  what does it do ?

[Haenk]

And the 5 pins white header near the 4 pins  what does it do ?

My guesstimate is "USB header" - a better picture would help (it's stated on the PCB, but only "SB" is readable).

[fzabkar]

LDO = low dropout, used to describe a linear regulator which can work in environments where there is a low differential between input and output.

[Yamin]

Wow, thanks so much guys! Its getting very exciting. I shall take a picture first thing in the morning when I get into the shop and upload it here.

[Yamin]

Here are some close up photos of the connectors.

[fzabkar]

I'm just curious. What are the complete markings on the ACT8846 chip? Is there a "490" marking anywhere?

[Yamin]

I'm just curious. What are the complete markings on the ACT8846 chip? Is there a "490" marking anywhere?

There is no marking "490" may I ask what that means?

[fzabkar]

There are different versions of the ACT8846 which are preprogrammed with different voltages and different power-up sequences for each specific SoC. The RK3288 requires the ACT8846QM490 version (see pages 3 & 34 of datasheet).

[jboy32]

Hi all
First of all, happy new year 2022 
I'm owner of a 2nd hand HR Pedalboard, and facing a known issue on this pedalboard effect that is related to USB.

USB connect to my laptop has been working twice, but since 2 weeks, no possibility to connect, I have checked the USB wire with some others, tested on 3 different laptop with different OS running on, and different USB port. I still doesn't work.

I have been reading different forum speaking about this known issue where, Headrush sometime fix it by changing the motherboard, or you need to buy a new one an fix it yourself ... when you see the original price of the pedalboard and the cost for a new motherboard, that is just amazing 

Mine still power up, but I can't add new IR or RIG because of the USB issue ... I have been looking inside the main motherboard that you are speaking about on this forum, and I'm wondering what could be the 2 buttons (Reset / Recovery ) ?

[jboy32]

Some updates on my investigations

After having unmounted the pedalboard, I found a motherboard that looks like the one of MPC Live.
I have connected a wire Serial to USB and use TeraTerm.

I have errors in the output of the terminal connected during the boot sequence :
...
001: dwc2 ff540000.usb: ff540000.usb supply vusb_d not found, using dummy regulator
001: dwc2 ff540000.usb: ff540000.usb supply vusb_a not found, using dummy regulator
001: dwc2 ff540000.usb: dwc2_check_params: Invalid parameter lpm_clock_gating=1
001: dwc2 ff540000.usb: dwc2_check_params: Invalid parameter besl=1
001: dwc2 ff540000.usb: dwc2_check_params: Invalid parameter hird_threshold_en=1
...
001: usb5537 1-002d: Failed to write config file
001: usb5537 1-002d: failed to switch mode: -6
...

I have then a prompt for login, it is a linux running, but no chance to log into with root even with blank password 

Also when I put the headrush in Update Firmware mode from the screen touch (same as starting with recovery button on the motherboard), in the output of the terminal, I have this message

Starting fastboot...
ERROR: usb5537_write_config: failed to write config file: ret=-121

at drivers/misc/usb5537.c:69/usb5537_write_config()
ERROR: board_usb_init: failed to probe usb5537@2d: ret=-121

at board/inmusic/az01/az01.c:525/board_usb_init()
otg_phy_init

I don't know if that could be a software issue or hardware issue for the moment but if those information can help to investigate let me know   

[coromonadalix]

Hum if i recall  you have Rockchip tools (softwares) to  format / install ose's / boot files etc ...

http://opensource.rock-chips.com/wiki_RK3288


forum.xda-developers.com  is a very good source for help and softwraes links, memory locations  etc ...


The recovery button should help,  do you see something on the serial console upon powering it up with recovery pressed ??

This board is a computer but only the I2S  interface (flat cable) seems to be used ??   

Is the pedal maker  can send you a recovery file if you mail them,  some special application file / os  etc ... may be needed for the recovery

We dont have many details to work with,  company / model can or could help ?

And i see you have posted at least 2 times on other web sites

[jboy32]

Hi, thanks for your answer,

Here is a link to all technical details of the pedalboard https://apps.fcc.gov/oetcf/eas/reports/ViewExhibitReport.cfm?mode=Exhibits&RequestTimeout=500&calledFromFrame=Y&application_id=nkZwk1kzGEhR9dsGu%2FseSA%3D%3D&fcc_id=Y4O-MG01

The exact reference is : InMusic AZ01 CR PCB 9-40-0752-C / 9-79-0752-C 2017-FEB-14 Most of MPC stuff from AKAI are based on the same motherboard.

Replacement part looks like this https://instrumentalparts.com/pcb-carrier-assembly-headrush/



Yes it is based on a RK3288, I have contacted Headrush to get the root password and a recovery file but no answer, just paying so they might potentially fix it but for lot money ... I posted also on MPC AKAI forums in case of similar known issue.

When I boot in Recovery mode, I have this output :

U-Boot SPL 2016.05-inmusic-20170317 (Apr 13 2017 - 19:55:47)
Trying to boot from MMC1


U-Boot 2016.05-inmusic-20170317 (Apr 13 2017 - 19:55:47 +0200), Build: jenkins-RadXa CustomBuilder-1459

Model: Eleven
DRAM:  1 GiB
MMC:   dwmmc@ff0f0000: 0
In:    gpio-keys
Out:   serial
Err:   serial
Hit any key to stop autoboot:  0
Starting fastboot...
ERROR: usb5537_write_config: failed to write config file: ret=-121

at drivers/misc/usb5537.c:69/usb5537_write_config()
ERROR: board_usb_init: failed to probe usb5537@2d: ret=-121

at board/inmusic/az01/az01.c:525/board_usb_init()
otg_phy_init


It confirms that there is an issue with USB port ...

I will have a look to forum.xda-developers.com that could help a lot 

[coromonadalix]

We do see RADXA  logo on the fcc aproval   board   links provided

Maybe they have some tools of firmware to help ??


You best luck   will be   someone who could extract the boot / config files     seems like somekind of memory corruption ??

Does it boot on the SD-Card ??     

Our embedded boards had some problems with sd-card ''wear and tear''   we had Kingston before and had to choose Sandisk, lots of problems where solved


If you search this wiki  :  https://fr.wikipedia.org/wiki/Rockchip_RK3288

You will see many derived  RK3288  boards

Maybe you could find some development tools and os to boot from or recover some parts ??

or Radxa home :

https://wiki.radxa.com/Home
https://wiki.radxa.com/Rock2/bringup


Akai MPC Live ??
https://niklasnisbeth.gitlab.io/mpc-internals/#the-software  seems to point to an OS  and files ??


Unless the usb driver chip has some problems,  check if you have an usb interface chip  somewhere  outside the SOM RK3288 module, maybe its kinda busted on one chanel ?

[Nominal Animal]

So, this is HeadRush Pedalboard, right?

In simple terms, the device is an embedded Linux appliance: a small single-board computer using RockChip RK3288 System-On-Chip, running some variant of Linux, and some userspace software providing the user interface.

at drivers/misc/usb5537.c:69/usb5537_write_config()
ERROR: board_usb_init: failed to probe usb5537@2d: ret=-121

USB5537 refers to an USB 3.0/2.0 7-port hub.  In the image, you can see at least three of them exposed in pin headers (but without any pins); some of the unpopulated connectors near the top of the image are also USB ports.

However, I cannot find the kernel driver, drivers/misc/usb5537.c, anywhere.  It is obviously an out-of-tree driver for thus USB hub, not developed by open-source developers (definitely not kernel.org) and it is not in RockChip kernel trees either.  It is the first point I'd start looking for a problem, but since the sources are nowhere to be found, it's a no go.  Apparently, copyright law is not something HeadRush is interested in following.

None of the HeadRush firmware files or user guides mention Linux. The license they are breaking by not providing sources for the modified Linux kernel they are using, is the only thing that permits them to use the Linux kernel in their product.  This means that software-wise, none of the Linux kernel developers like myself can help you with this.

If I were you, I'd raise a fuckstink at HeadRush for breaking copyright law, and not providing the sources for the GPL-licensed software they are selling as a key part of this device.

If you at some point do get the exact sources for at least the kernel used in the product –– and that means the exact ones, including the usb5537.c file, and not just "it's a 4.4 kernel" because the fuck it is; the 4.4 kernels do not have that file nor are able to produce that error output you are getting, and what is used on that thing is not a normal Linux kernel, but a modified one ––, then it would be a quick matter of checking out the usb5537 driver if it could be the source of the issues.  Who knows, it might have an obfuscated check to stop operating after some (randomized) interval, just to make sure you guitarists keep buying new pedalboards.
(Really, it's more like how fragile the driver is wrt. timeouts, response intervals and such, that change as the hardware ages and things like capacitors degrade a little bit.  It is easy to write a driver that works with perfect hardware, but a proper driver that is robust against that kind of variation, requires common sense and a lot of experience.  Which cheap developers that copy-paste code from the internet –– which is what the names shown in the log indicates; I can see similar names in microcontroller examples for controlling the USB5537B chip, which indicates that the "driver" is basically a copy-paste hack-job to get the hub chip "working".  And because it is a low-grade hack, it often doesn't, causing a lot of lost money and wasted pedalboards.  HeadRush doesn't mind, because you customers keep buying new devices to replace the "broken" ones.)

The reason I'm so angry is that customers don't care, and tend to just blame us open source developers for making "a crappy Linux that failed in my pedalboard".  Because we didn't, HeadRush did, by fucking with the kernel.  The results you have in your hands, with HeadRush laughing at us all the way to the bank.  And RockChip (the designers of the RK3x88 chips) happens to be one of the rare Chinese designer firms that do publish the changes needed for the Linux kernel to support their chips and even push changes to the upstream Linux kernel developers; companies like Allwinner just give a middle finger to everybody, because they cannot be sued in any Western country for copyright violations, they don't need to care.  So, this is Annoying.

Besides, even if one would get full sources to the kernel, HeadRush will never ever publish enough sources for you to generate a replacement firmware fixing the software issue –– assuming it is one ––, so you're fucked with this thing anyway.  (Even if somebody like me finds the bug in the driver, and provides a fix, what is the likelihood that HeadRush accepts the fix and produces a new firmware fixing the issues?  They'd only be reducing their future sales, because their old products would be usable for longer.)

Unless, of course, it is a pure hardware issue.  Which I don't think it is, because it works well enough to boot into the Linux kernel.

[jboy32]

Hi guys, thanks a lot for your contributions

@Nominal Animal, I confirm it is a headrush pedalboard.

I'm now able to login on serial port as root.
When the Headrush was booting, I was stopping boot at the beginning by typing any key, to be in "low boot level" ...
Then, what I did :

$>printenv bootargs
$>bootargs=root=PARTUUID=24d1deac-3434-1a4e-98d1-68ee2945a5f1 rootwait ro console=ttyS2,115200 rfkill.default_state=0
$>setenv bootargs 'root=PARTUUID=24d1deac-3434-1a4e-98d1-68ee2945a5f1 rootwait ro console=ttyS2,115200 rfkill.default_state=0 single init=/bin/sh'
$>boot
$>mount -rw -o remount /
$>passwd root
$>reboot -f

Then I was able to log as root into the headrush.

I'm not a Linux expert, I use to work with like 20 years ago ... but as you said I would be surprise that it is a hardware issue ... I agree with you they don't give any access to source code ... I emailed AKAI support to get a fix but no possibility to get any software assistance, just send the unit back on my own cost then they will have a look to fix it.

There is no SD card on the board. There are some logs still running and making the FS growing 
I'm  technical guy and I like to understand why things are not working well, in that case if it is a software issue, it should be an easy one to fix it instead of a hardware issue and save lot of money for music players.

$>dmessg
...
[    0.078590] phy phy-ff770000.syscon:usbphy.0: Looking up phy-supply from device tree
[    0.078597] phy phy-ff770000.syscon:usbphy.0: Looking up phy-supply property in node /syscon@ff770000/usbphy/usb-phy@320 failed
[    0.078656] phy phy-ff770000.syscon:usbphy.0: Looking up vbus-supply from device tree
[    0.078661] phy phy-ff770000.syscon:usbphy.0: Looking up vbus-supply property in node /syscon@ff770000/usbphy/usb-phy@320 failed
[    0.078853] phy phy-ff770000.syscon:usbphy.1: Looking up phy-supply from device tree
[    0.078858] phy phy-ff770000.syscon:usbphy.1: Looking up phy-supply property in node /syscon@ff770000/usbphy/usb-phy@334 failed
[    0.078899] phy phy-ff770000.syscon:usbphy.1: Looking up vbus-supply from device tree
[    0.078904] phy phy-ff770000.syscon:usbphy.1: Looking up vbus-supply property in node /syscon@ff770000/usbphy/usb-phy@334 failed
[    0.079080] phy phy-ff770000.syscon:usbphy.2: Looking up phy-supply from device tree
[    0.079085] phy phy-ff770000.syscon:usbphy.2: Looking up phy-supply property in node /syscon@ff770000/usbphy/usb-phy@348 failed
[    0.079125] phy phy-ff770000.syscon:usbphy.2: Looking up vbus-supply from device tree
[    0.079130] phy phy-ff770000.syscon:usbphy.2: Looking up vbus-supply property in node /syscon@ff770000/usbphy/usb-phy@348 failed
[    0.079721] pwm-backlight mipi-backlight: Looking up power-supply from device tree
...

[    1.761182] dwc2 ff540000.usb: Looking up vusb_d-supply from device tree
[    1.761188] dwc2 ff540000.usb: Looking up vusb_d-supply property in node /usb@ff540000 failed
[    1.761208] dwc2 ff540000.usb: ff540000.usb supply vusb_d not found, using dummy regulator
[    1.761247] dwc2 ff540000.usb: Looking up vusb_a-supply from device tree
[    1.761252] dwc2 ff540000.usb: Looking up vusb_a-supply property in node /usb@ff540000 failed
[    1.761264] dwc2 ff540000.usb: ff540000.usb supply vusb_a not found, using dummy regulator
[    1.761393] dwc2 ff540000.usb: Looking up vbus-supply from device tree
[    1.761399] dwc2 ff540000.usb: Looking up vbus-supply property in node /usb@ff540000 failed
[    1.812571] dwc2 ff540000.usb: dwc2_check_params: Invalid parameter lpm_clock_gating=1
[    1.812576] dwc2 ff540000.usb: dwc2_check_params: Invalid parameter besl=1
[    1.812579] dwc2 ff540000.usb: dwc2_check_params: Invalid parameter hird_threshold_en=1
[    1.812699] dwc2 ff540000.usb: DWC OTG Controller
[    1.812714] dwc2 ff540000.usb: new USB bus registered, assigned bus number 1
[    1.812851] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.04
[    1.812857] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    1.812861] usb usb1: Product: DWC OTG Controller
[    1.812864] usb usb1: Manufacturer: Linux 5.4.115-inmusic-2021-04-30-rt56 dwc2_hsotg
[    1.812867] usb usb1: SerialNumber: ff540000.usb
[    1.813152] hub 1-0:1.0: USB hub found
[    1.813174] hub 1-0:1.0: 1 port detected
[    1.813502] dwc2 ff580000.usb: Looking up vusb_d-supply from device tree
[    1.813508] dwc2 ff580000.usb: Looking up vusb_d-supply property in node /usb@ff580000 failed
[    1.813523] dwc2 ff580000.usb: ff580000.usb supply vusb_d not found, using dummy regulator
[    1.813599] dwc2 ff580000.usb: Looking up vusb_a-supply from device tree
[    1.813605] dwc2 ff580000.usb: Looking up vusb_a-supply property in node /usb@ff580000 failed
[    1.813618] dwc2 ff580000.usb: ff580000.usb supply vusb_a not found, using dummy regulator
[    1.813744] dwc2 ff580000.usb: Looking up vbus-supply from device tree
[    1.813750] dwc2 ff580000.usb: Looking up vbus-supply property in node /usb@ff580000 failed
[    1.935570] dwc2 ff580000.usb: dwc2_check_params: Invalid parameter lpm_clock_gating=1
[    1.935575] dwc2 ff580000.usb: dwc2_check_params: Invalid parameter besl=1
[    1.935578] dwc2 ff580000.usb: dwc2_check_params: Invalid parameter hird_threshold_en=1
[    1.935592] dwc2 ff580000.usb: EPs: 10, dedicated fifos, 972 entries in SPRAM
[    1.935651] dwc2 ff580000.usb: DWC OTG Controller
[    1.935665] dwc2 ff580000.usb: new USB bus registered, assigned bus number 2
[    1.935773] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.04
[    1.935778] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    1.935782] usb usb2: Product: DWC OTG Controller
[    1.935785] usb usb2: Manufacturer: Linux 5.4.115-inmusic-2021-04-30-rt56 dwc2_hsotg
[    1.935788] usb usb2: SerialNumber: ff580000.usb
[    1.936093] hub 2-0:1.0: USB hub found
[    1.936113] hub 2-0:1.0: 1 port detected

$># lsusb -v
Bus 003 Device 001: ID 1d6b:0002
Bus 001 Device 001: ID 1d6b:0002
Bus 001 Device 002: ID 0763:0016
Bus 002 Device 001: ID 1d6b:0002

I have seen that there are known issues with the fact that USB port could be in a bad situation, specifically for those where you plug/unplug USB wire without unmounting properly.
It seems that there is a potential solution there https://lkml.org/lkml/2016/8/21/29 but I don't know how I can apply that.
or https://linux-arm-kernel.infradead.narkive.com/Q7dsQsVn/patch-3-4-arm-dts-rockchip-enable-the-usb-phys-as-reset-providers-on-rk3288
I didn't find anything in the tree of the unit 

As you said unless if they give the source code to fix in usb5537.c or other files they might not accept to integrate into future release.
When I see on music forums number of music players impacted by this issue without good responses of headrush support.
https://www.thegearpage.net/board/index.php?threads/headrush-usb-problem.1890675/

@coromonadalix thanks for the links I will have a look.