[WII-EXT] Random button press using Hakchi CE Kernel

[darthcloud]

Data transmission look fine on the scope but somehow the Hakchi kernel see random button press.

More often it's button A which is the 3rd bit in the 2nd byte of the button bitfield. So not a sampling timing issue as the previous and next bit are unset.

Really no idea about this one :(

With original kernel I never see random press, gone through SMW and got 96 Exits.

[DanTheMan827]

If it's of any use, the diff between the stock snes kernel module and the modified one can be found here

https://www.diffchecker.com/UtjYqJuA

Also, here are the raw files: old / new

[DanTheMan827]

Also, does this also happen with the stock kernel of the NES classic as well?

[darthcloud]

@DanTheMan827 this is very helpful insight. Thanks!

Is there some developer documentation for building the kernel and packaging it with the hakchi application?

What I would like to do is revert the change to the linux i2c controller driver so that the only the required /etc/preinit stuff is left and try to install it this way on my SNES mini to see if I still get the ramdom press.

If it go away, then I would work to try adding a few changes back in the driver at a time, until it brake so I can pin point more precisely what is the issue.

Then I could probably figure if it's something I can fix within BlueRetro.

[DanTheMan827]

the kernel with modified clovercon can be found here

it's been a while since I built it, but assuming you have an arm toolchain installed I don't think there's anything that would prevent you from building it.

I did make a docker container with the entire toolchain in it though, that would probably help a bit
https://hub.docker.com/repository/docker/dantheman827/buildroot-2015.11.1

the build_all.sh script should build the kernel as well as clovercon.hmod

[darthcloud]

Awesome, will try later tonight. Thanks

btw I don't have a nes mini so I didn't test with it.

[DanTheMan827]

Okay, so I did a little testing and I guess my system has a bit more than just the toolchain.

the build script wants Qt, arm-linux-gnueabihf toolchain, and sntool from the hakchi repo

If I had to guess, I'm thinking it might be a noisy signal, especially if you're putting more stress on the power of classic itself

One thing you could maybe try is powering the entire adapter on battery

[darthcloud]

@DanTheMan827 Maybe but I'm tap directly onto the USB cable 5V input (ESP32 use it's own power reg) and I use the original 1.5A AC adapter.
Combined power consumption for mini and ESP32 I measured was well under 1A.
It work 100% fine with the original kernel.

I think it could be a subtle issue with the I2C frames that I can't catch with the scope nor the logic analyzer.

So I'm curious to find which kernel changes trigger that.

So I was able to build the kernel image and the driver module:

deneb[master]~/hakchi/3rdparty/sun-nontendocm-kernel$ ll ./arch/arm/boot/zImage
-rwxrwxr-x 1 jacques jacques 2457112 Jun 14 19:53 ./arch/arm/boot/zImage*
deneb[master]~/hakchi/3rdparty/sun-nontendocm-kernel$ ll clovercon/mod/etc/preinit.d/pc000_clovercon
-rwxrwxr-x 1 jacques jacques 1103 Jun 14 19:05 clovercon/mod/etc/preinit.d/pc000_clovercon*
deneb[master]~/hakchi/3rdparty/sun-nontendocm-kernel$ ll clovercon/clovercon.ko
-rw-rw-r-- 1 jacques jacques 16356 Jun 14 19:55 clovercon/clovercon.ko

But now I'm a bit lost at what is the next step is to get that onto my snes mini.

I guess I need to somehow package that and put it in the hakchi2 user_mods directory?

Thanks for help! very appreciated!

[darthcloud]

I got a fix coming in the next release for this.

Background: The SNES mini is reading an extra 13 bytes in addition to the 8 bytes of data when doing the controller polling. A regular Wii extension will answer with 0x00 when polled for extra data. The ESP32 I2C peripheral will answer 0xFF when polled for extra data. The SNES mini original driver doesn't like it when the extra data is 0xFF and so to work around this BlueRetro add an extra 13 0x00s into the ESP32 I2C TX FIFO. Doing so work 100% ok with the original SNES mini firmware.

I haven't took time to look at the Hakchi clovercon source TBH but I suspect the change make it read sometimes less than 8 + 13 bytes. Since less data is read the ESP32 TX FIFO flush come into play and is important to make sure the extra queued data is discarded before BlueRetro queue the new data. The random input appear because the ESP32 TX FIFO flush wasn't working all the time. The flush was done right before queuing the data. Look like doing so sometimes the flush fail and the data sent is shifted by some bytes. Flushing TX FIFO twice with a delay of 25us after each flush fix the issue.