Not responsive at bootup or at login screen

[denolfe]

I'm having an issue with my GH60 Satan not being responsive at startup or the Windows 10 login screen.

If I unplug and replug the keyboard, the functionality returns to normal. Any ideas what may be causing this behavior?

[jackhumbert]

That's interesting - does it act the same with the backlight disabled? It could be something with SLEEP_LED_ENABLE if you have that enabled (in your Makefile).

[denolfe]

Hmm, I recreated this twice yesterday, but now it seems I cannot backlight on or off. I know for sure that my backlight was on overnight after powering down, and I recreated it when booting up today. I'll try and see if I can recreate this in the next few days. Also, I currently do not have SLEEP_LED_ENABLE in my Makefile.

[jackhumbert]

I wonder if the keyboard crashed/got reset between shutting the computer down and starting it back up. The keyboard design isn't really sufficiently protected from static, and will go into dfu/reset mode when zapped.

[denolfe]

Hmm, happened again booting up fresh without backlight enabled (except CapsLock led). Is there any method I can use to troubleshoot this?

[jackhumbert]

Do you know how long it was sitting plugged in before it happened? One thing you could check is to see if the keyboard is on, ie status led on or anything. I'm thinking it may be getting put in DFU mode somehow. One test would be to see if you could cycle through the backlight settings if you don't have a status led.

That won't prove it's in DFU mode though - it could just not be getting power.

[denolfe]

It was sitting for close to 12 hours with just the CapsLock LED on, so it was definitely getting power. I tried turning the LEDs on and also cycle the levels without any response.

Life before, unplugging and replugging brought it back to normal.

[jackhumbert]

Will it successfully cycle through the backlight levels? That won't send the wake-up command to the computer, but should still function w/o a USB connection.

[denolfe]

Not sure if this helps or makes it more confusing, but I was able to cycle through the LEDs for part of the bootup, then was unable to during the end.

When it booted up, input was working, but wasn't typing the correct characters. When I tried the following keys, the characters below were output.

z -> Alt+s?? x -> de3 c -> fr4 v -> gt5 b -> hy6 n -> ju7 m -> ki8

[jackhumbert]

Ahh. Yeah, I had this exact thing happen today on both of my boards. Confirmed bug :)

Right now, my guess is the matrix_power_up function in quantum/matrix.c - I think the toggle_pin may be causing the trouble. If you'd like to nuke the whole function to test, that would be a good test too!

[calvn]

Did commenting out matrix_power_up end up working as a fix for this?

[jackhumbert]

I implemented this this on master, and it hasn't happened again for me! @denolfe if you can confirm the status on your end, that would be awesome!

[calvn]

I can also flash on mine to test :)

[jackhumbert]

@cleung2010 that would be great! :)

[denolfe]

Away from my keyboard until next week. If others can test, that would work. Or I'll reopen if I still see issues.

[calvn]

@jackhumbert bumped into an error while flashing..

make dfu                                                                                                                                                                [ba636c1]

Size after:
   text    data     bss     dec     hex filename
      0   19054       0   19054    4a6e planck_rev4_calvin.hex

Erasing flash...  Success
Checking memory from 0x0 to 0x6FFF...  Empty.
Checking memory from 0x0 to 0x4A7F...  Empty.
0%                            100%  Programming 0x4A80 bytes...
[ X  ERROR
Memory write error, use debug for more info.
make: *** [dfu] Error 6

[jackhumbert]

Usually rerunning the command fixes that. Can you try these commands?

dfu-programmer atmega32u4 erase --force --debug 1000
dfu-programmer atmega32u4 flash planck_rev4_calvin.hex --debug 1000
dfu-programmer atmega32u4 reset --debug 1000

[calvn]

Weird, getting a timeout every time at this particular point:

...
dfu.c:163: Message: m[1066] = 0xff
dfu.c:163: Message: m[1067] = 0xff
dfu.c:163: Message: m[1068] = 0xff
dfu.c:163: Message: m[1069] = 0xff
dfu.c:163: Message: m[1070] = 0xff
dfu.c:163: Message: m[1071] = 0xff
libusb: warning [darwin_transfer_status] transfer error: timed out
dfu.c:844: -ETIMEDOUT: Transfer timed out, NAK 0xffffffc4 (-60)
atmel.c:1627: atmel_flash: flash data dfu_download failed.
atmel.c:1629: Expected message length of 1072, got -60.
atmel.c:1434: Error flashing the block: err -2.
ERROR
Memory write error, use debug for more info.
commands.c:360: Error writing memory data. (err -4)

[jackhumbert]

That's odd - are you using a USB hub? Similar things have happened when my USB stuff was messed-up on OS X, and are sometimes fixed by plugging in directly, or restarting the computer.

[calvn]

I have it plugged in directly. dfu-programmer atmega32u4 erase --force --debug 1000 works fine too.

I can't flash the previous version either.. Did I brick my keyboard..?

[calvn]

It's worth noting that when I run make to generate the .hex this warning pops up, wondering if it's relevant:

$ make
-------- begin --------
WARNING:
 Some git sub-modules are out of date or modified, please consider runnning:
 git submodule sync --recursive
 git submodule update --init --recursive

 You can ignore this warning if you are not compiling any ChibiOS keyboards,
 or if you have modified the ChibiOS libraries yourself. 

[jackhumbert]

Yeah, the sub-module stuff is just for the new ChibiOS stuff (ARM support).

Do you have another computer you could try this on? A restart might help, too.

Are you running 0.7.0 of dfu-programmer? (dfu-programmer --version)

[calvn]

A restart on my computer didn't help :(

$ dfu-programmer --version
dfu-programmer 0.7.2

Flashing the default keymap also results in the same error.

Edit: Found a related issue on SourceForge (dated 2007) - https://sourceforge.net/p/dfu-programmer/mailman/dfu-programmer-user/?page=15.

[jackhumbert]

Can you post the full output of the flash command?

I feel like we should handle this somewhere else - would you mind moving to /r/olkb?

[fredizzimo]

Also does reading the firmware with dfu-programmer atmega32u4 read out.hex succeed? If that succeeds then at least it would confirm that the USB connection and keyboard is working properly. I'm just guessing here, but it that works, it could also mean that the flash memory has reached the maximum amount of writes it can take.

[calvn]

Here is the following on the subreddit with the logs: https://www.reddit.com/r/olkb/comments/4rjzen/flashing_error_on_mac_os_x/

I had to crop out the first 300 messages due to the max size (40k characters) that Reddit permits per post.

[calvn]

@fredizzimo it does not seem to be a valid command. At this point I am just trying to flash the default keymap.

$ dfu-programmer atmega32u4 read planck_rev4_default.hex
dfu-programmer 0.7.2
https://github.com/dfu-programmer/dfu-programmer
Usage: dfu-programmer target[:usb-bus,usb-addr] command [options] [global-options] [file|data]

global-options:
        --quiet
        --debug level    (level is an integer specifying level of detail)
        Global options can be used with any command and must come
        after the command and before any file or data value

command summary:
        launch       [--no-reset]
        read         [--force] [--bin] [(flash)|--user|--eeprom]
        erase        [--force] [--suppress-validation]
        flash        [--force] [(flash)|--user|--eeprom]
                     [--suppress-validation]
                     [--suppress-bootloader-mem]
                     [--serial=hexdigits:offset] {file|STDIN}
        setsecure
        configure {BSB|SBV|SSB|EB|HSB} [--suppress-validation] data
        get     {bootloader-version|ID1|ID2|BSB|SBV|SSB|EB|
                 manufacturer|family|product-name|
                 product-revision|HSB}
        getfuse {LOCK|EPFL|BOOTPROT|BODLEVEL|BODHYST|
                 BODEN|ISP_BOD_EN|ISP_IO_COND_EN|
                 ISP_FORCE}
        setfuse {LOCK|EPFL|BOOTPROT|BODLEVEL|BODHYST|
                 BODEN|ISP_BOD_EN|ISP_IO_COND_EN|
                 ISP_FORCE} data

additional details:
 launch: Launch from the bootloader into the main program using a watchdog
         reset.  To jump directly into the main program use --no-reset.
   read: Read the program memory in flash and output non-blank pages in ihex
         format.  Use --force to output the entire memory and --bin for binary
         output.  User page and eeprom are selected using --user and --eeprom
  erase: Erase memory contents if the chip is not blank or always with --force
  flash: Flash a program onto device flash memory.  EEPROM and user page are
         selected using --eeprom|--user flags. Use --force to ignore warning
         when data exists in target memory region.  Bootloader configuration
         uses last 4 to 8 bytes of user page, --force always required here.
Note: version 0.6.1 commands still supported.

[calvn]

$ dfu-programmer atmega32u4 read --debug 1000
     target: atmega32u4
    chip_id: 0x2ff4
  vendor_id: 0x03eb
    command: read
      quiet: false
      debug: 1000
device_type: AVR
------ command specific below ------

dfu.c:414: dfu_device_init( 1003, 12276, 0x7fff5f327450, true, false )
dfu.c:431: found device at USB:31,0
dfu.c:663: Found DFU Inteface: 0
dfu.c:293: dfu_abort( 0x7fff5f327450 )
dfu.c:204: dfu_get_status( 0x7fff5f327450, 0x7fff5f327358 )
dfu.c:230: ==============================
dfu.c:232: status->bStatus: OK (0x00)
dfu.c:233: status->bwPollTimeout: 0x0001 ms
dfu.c:235: status->bState: dfuIDLE (0x02)
dfu.c:236: status->iString: 0x00
dfu.c:237: ------------------------------
dfu.c:688: State: dfuIDLE (2)
atmel.c:756: atmel_read_flash( 0x7fff5f327450, 0x7fff5f327340, 0, false )
atmel.c:1041: atmel_select_memory_unit( 0x7fff5f327450, 0 )
atmel.c:1055: Ignore Select Memory Unit for non GRP_AVR32 device.
Reading 0x7000 bytes...
atmel.c:1100: atmel_select_page( 0x7fff5f327450, 0 )
atmel.c:1114: Selecting page 0, address 0x0.
dfu.c:142: dfu_download( 0x7fff5f327450, 4, 0x7fff5f327284 )
dfu.c:163: Message: m[0] = 0x06
dfu.c:163: Message: m[1] = 0x03
dfu.c:163: Message: m[2] = 0x00
dfu.c:163: Message: m[3] = 0x00
dfu.c:204: dfu_get_status( 0x7fff5f327450, 0x7fff5f327290 )
dfu.c:230: ==============================
dfu.c:232: status->bStatus: OK (0x00)
dfu.c:233: status->bwPollTimeout: 0x0001 ms
dfu.c:235: status->bState: dfuIDLE (0x02)
dfu.c:236: status->iString: 0x00
dfu.c:237: ------------------------------
dfu.c:142: dfu_download( 0x7fff5f327450, 6, 0x7fff5f327298 )
dfu.c:163: Message: m[0] = 0x03
dfu.c:163: Message: m[1] = 0x00
dfu.c:163: Message: m[2] = 0x00
dfu.c:163: Message: m[3] = 0x00
dfu.c:163: Message: m[4] = 0x03
dfu.c:163: Message: m[5] = 0xff
dfu.c:844: -EPIPE: a) Babble detect or b) Endpoint stalled 0xffffffe0 (-32)
atmel.c:717: dfu_download failed
atmel.c:828: Error reading block 0x0 to 0x3FF: err -1.
ERROR
Memory read error, use debug for more info.
commands.c:619: ERROR: could not read memory, err -5.

[jackhumbert]

If anyone comes to this thread in the future, we now have this guide for ISP flashing!

[tuananh]

i'm having the same issue. @jackhumbert may i ask what's the actual fix for this? the link seems dead.