RPi4 - Toneboard not recognized on DualPower


Just got myself a Toneboard.
I’m running the TB attached to an RPi4 (Raspbian)

If I connect the TB straight to RPi-USB all is fine.

Now the issue starts when running dual-power-rails
I have an Allo Shanti PS, which comes with two 5V rails.
One rail powers the PI and the other one the Toneboard.
I accomplish this by feeding the TB using an iFi iDefender3.0
breakout adapter.

The TB simply doesn’t get recognized all the time this way.
I already changed the “rootdelay” param to avoid that the RPi boots up before
the TB is up’n running.

lsusb doesn’t show the XMOS device in this case.
reboot doesn’t change the situation.

Any idea what else I could try?


Can you take a photo and show us the connection between the KTB, RPi, and the iDefender3.0?


Two USB cables and the iDefender!?!? Photo?

I ran some more tests.

I added boot_delay=10 to /boot/config.txt of the PI4 to
give the TB a chance to power up properly. This had no effect.

The Allo Shanti is a DualPS with two isolated 5V rails.
Both rails can only be turned on simultaneously.

I do get the DAC up’n running if I manually detach both power cables
and then attach the DAC power cable first,
followed by attaching the RPI PS cable short after.

I now tried powering the TB through the GPIO. Which also has it’s issues.
The TB, and I guess the XMOS chip in particular, seems to require
VBUS and GND on this Khadas board.

In another thread it was explained by Khadas, that the TB “switches” to GPIO power as soon as it recognizes it.

I did figure out that by cutting the VBUS/GND nothing happens. I have an adapter which accomplishes this.
Which basically confirms that 2 supplies are required if power gets applied through thw GPIOs. Not nice.

Back to my original issue. Now learning more and more about it. I do suspect that at a simultaneous power up of iDefender and RPI a switch from RPI-VBUS to iDefender takes place (you can hear it).
That short hiccup might cause the KHADAS TB to stall. And in this case the TB won’t recover (e.g. by automatic restart) to give the RPI a chance to reinitialize the driver.

Does this make sense?