search

kiibohd / controller

Kiibohd Controller
GNU General Public License v3.0
806 stars 270 forks source link

dc562cd bricks my Infinity board #53

Closed unphased closed 9 years ago

unphased commented 9 years ago

It's now responding (responding is not the right word) to a small subset of keys, and will repeat them about 30x.

The USB serial port debug interface will drop about 3 seconds after typing the first characters. As long as I don't type on it, the command line is quite responsive.

Seems very bricked because while I can update firmware with DFU util, it does not fix the behavior.

Can I rescue it by reloading the bootloader? (I don't have a bus pirate yet, but I just ordered one)

unphased commented 9 years ago

I was able to revive it by loading my NKRO disable branch.

This is bizarre

haata commented 9 years ago

Hmm, interesting. You shouldn't be able to affect the bootloader image because it's write-protected (well, unless you have a bus pirate). I'll, try to go through some other possibilities, but first, if you don't have cables around for the bus pirate get this (https://www.sparkfun.com/products/9556). You'll thank me later.

First, make sure the keyboard is outside of the case (if it's not a bent metal one). To rule out any possible shorts.

Next, inspect the pcb components and solder joints. Specifically, the usb connector.

If you have rev 2 of the infinity keyboard, you can use the Rx and Tx pins to get an external cmd line (you'll have to re-compile the firwmare and use either the uartOut or usbMuxUart Output module (I've been working on this code recently, so you might want to use the bringup branch if you run into compilation issues).

If you have an arch linux system/vm you'll be able to take advantage of my new manufacturing scripts (https://github.com/kiibohd/manufacturing).

haata commented 9 years ago

odd, please keep me posted.

unphased commented 9 years ago

I could get the command line working fine over the USB.

So that probably means its not a USB port problem. Now that it's "revived" i'll try loading it again with what I had before.

Maybe something about my binds it didn't like, and then I made builds with my new binds disabled, and it was still borked.

haata commented 9 years ago

I've been working on some bootloader enhancements for future keyboards (won't fit in the infinity's bootloader right now). One of them includes a debug terminal with some basic indications on why the keyboard reset/locked up.

unphased commented 9 years ago

I do have a large number of F-F/F-M/M-M jumper pin cables, I guess if the dot-pitch is 0.1 inch I can just cram ten of them into the header and make do with it.

unphased commented 9 years ago

Appears to be something in the last few commits, the ones from 26 hours ago. Since it's actually functioning I might as well find out which commit introduces the issue.

What's for sure is that this code worked for me for a number of reflashes, but now the hardware (or my Mac) is suddenly having none of it.

unphased commented 9 years ago

The issue is introduced in commit 622ea5d85f94be4b1694fdf08e30fa76eeb18fe4

Initial Remote Wakeup Support

haata commented 9 years ago

I've found that Mac OSX has driver caches. These have caused me many headaches in the past.

On Sat, Jun 13, 2015 at 8:43 PM Steven Lu notifications@github.com wrote:

Appears to be something in the last few commits, the ones from 26 hours ago. Since it's actually functioning I might as well find out which commit introduces the issue.

What's for sure is that this code worked for me for a number of reflashes, but now the hardware (or my Mac) is suddenly having none of it.

— Reply to this email directly or view it on GitHub https://github.com/kiibohd/controller/issues/53#issuecomment-111777892.

unphased commented 9 years ago

So if i load a firmware post that merge, the keyboard no longer works properly on Windows 7 or my Mac. It's too long ago now for me to be sure, but it may have worked fine for a little while after I merged, but to be honest now I'm not sure, because I think there was a period when I didnt flash after I did the merge.

At this point it is 100% the Remote Wakeup USB code change that is causing this for me.

I can easily work around this I think, by keeping a branch with that commit reverted out.

haata commented 9 years ago

kk, I'll look into it further.

I'm getting closer to doing a big code merge for the mk20dx256vlh7 support (Infinity ErgoDox and a future keyboard).

I've acquired more machines and testing equipment since I last looked at USB wakeup issues so maybe this will be easier to debug.

On Sat, Jun 13, 2015 at 8:48 PM Steven Lu notifications@github.com wrote:

So if i load a firmware post that merge, the keyboard no longer works properly on Windows 7 or my Mac. It's too long ago now for me to be sure, but it may have worked fine for a little while after I merged, but to be honest now I'm not sure, because I think there was a period when I didnt flash after I did the merge.

At this point it is 100% the Remote Wakeup USB code change that is causing this for me.

— Reply to this email directly or view it on GitHub https://github.com/kiibohd/controller/issues/53#issuecomment-111777997.

unphased commented 9 years ago

No worries, reverting does the trick for me.

Keep doing what you do! :smiley:

haata commented 9 years ago

I'm putting together a test setup to work on fixing this (along with the USB wake-up issues). We'll see if I can root cause the issue.

bburky commented 9 years ago

I also had this issue on OSX. Serial interface is completely functional (using an alternate keyboard) until the first keypress on my Infinity, at which point it stops responding completely. I cannot type at all with it. The bootloader was unaffected, I can flash a working firmware back onto it and it's fine.

A git revert -m1 622ea5d85f94be4b1694fdf08e30fa76eeb18fe4 fixes it. Maybe revert this out of master until its fixed?

haata commented 9 years ago

Reverting until I get the usb analyzer