Can't flash infinity_chibios_default.hex

[Petrosophia]

I'm unable to flash my compiled firmware using make dfu, make program, or the QMK Firmware Flasher program for Windows. The first two are done on Ubuntu and produce no results at all. The firmware flasher never allows me to click the flash button, which makes it seem like it's not detecting that the keyboard has had the reset button pressed. I did also try flashing via the kii-dfu Windows program, which "worked;" the .hex file got flashed, and the keyboard would no longer do anything, but as soon as I flashed TMK again (using sudo make -f Makefile program), things were back to normal.

For what it's worth, KLL/Kiibohd flash a .bin, not a .hex, and the TMK version of infinity_chibios outputs a handful of files, one of which is a .bin.

Is there something I'm doing wrong, or is this an actual problem?

[fredizzimo]

Sorry for the poor instructions. Some instructions are going to be added as part of #503, and more a little bit later.

However, you need to run make dfu-util to flash the firmware.

And if you are doing it manually, you need to flash the .bin file, not the .hex one. I will remove the hex files completely for the Ergodox Infinity at some point.

[Petrosophia]

It's a work in progress, so I understand!

I suppose I wasn't entirely clear, but I've got two Infinity 60% boards, not an Infinity Ergodox. One is from drop 3 and one is from the most recent drop (4?).

When running make dfu-util, do I need to have a .bin? Because compiling QMK produced only the .hex, unless the .bin is hidden somewhere else.

[fredizzimo]

The process for Infinity 60% should be the same. But I don't think anyone has tested that keyboard yet, so I'm not sure if it's working or not. Also some versions might not work, since there's a pull request for the TMK firmware tmk/tmk_keyboard#371

The make dfu-util command should generate a bin file in addition to flashing the firmware. I think that make .build/target.bin where target is the same name as the .hex file, should also generate the bin file.

[Petrosophia]

tyler@Bookholm:~/qmk_firmware/keyboards/infinity_chibios$ make dfu-util
arm-none-eabi-gcc (4.8.2-14ubuntu1+6) 4.8.2
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Size before:
   text    data     bss     dec     hex filename
      0   24572       0   24572    5ffc infinity_chibios_default.hex


Size after:
   text    data     bss     dec     hex filename
      0   24572       0   24572    5ffc infinity_chibios_default.hex

dfu-util 0.5

(C) 2005-2008 by Weston Schmidt, Harald Welte and OpenMoko Inc.
(C) 2010-2011 Tormod Volden (DfuSe support)
This program is Free Software and has ABSOLUTELY NO WARRANTY

dfu-util does currently only support DFU version 1.0

Cannot open device 
Opening DFU USB device... make: *** [dfu-util] Error 1

and

tyler@Bookholm:~/qmk_firmware/keyboards/infinity_chibios$ make .build/infinity_chibios_default.hex
arm-none-eabi-gcc (4.8.2-14ubuntu1+6) 4.8.2
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Size before:
   text    data     bss     dec     hex filename
      0   24572       0   24572    5ffc infinity_chibios_default.hex

I do see at the end of the compilation that a .bin is generated, but I have no idea where it ends up.

Compiling: ../../lib/chibios/os/hal/lib/streams/memstreams.c                                        [OK]
Compiling: ../../lib/chibios/os/hal/lib/streams/nullstreams.c                                       [OK]
Assembling: ../../lib/chibios/os/common/startup/ARMCMx/compilers/GCC/crt0_v7m.S                     [OK]
Assembling: ../../lib/chibios/os/common/ports/ARMCMx/compilers/GCC/chcoreasm_v7m.S                  [OK]
Linking: .build/infinity_chibios_default.elf                                                        [OK]
Creating binary load file for Flash: .build/infinity_chibios_default.bin                            [OK]
Creating load file for Flash: .build/infinity_chibios_default.hex                                   [OK]

I feel like there's probably something silly that I'm doing wrong (like the make dfu-util thing above), since I don't really know much about this.

Thanks for pointing out that tmk pull request, though! I'll have to test that one out. I've been avoiding using my newest Infinity all that much because KLL doesn't let me use the keymap I really want.

[fredizzimo]

You have a quite old version of dfu-util, my version is 0.8. Some Ubuntu distributions does not seem to provide newer versions though. But if yours does then it should be easy to update with apt-get.

Otherwise you have to build it from the sources http://dfu-util.sourceforge.net/build.html.

If you want to flash it with windows, the bin file should be located in keyboards/infinity_chibios/.build note that the build directory is hidden so you need ls -a to see it.

[Petrosophia]

I was unable to update dfu-util with apt-get, but I did build and install from source like you suggested. It still wouldn't let me flash the firmware, which was odd, but since you told me where to find the .bin file (I feel dumb for not thinking of a hidden file), I was able to flash it with the kii-dfu Windows program that was distributed for flashing the Infinity board originally.

My new problem is that my keymap isn't working the way I expected. Looking at other QMK examples, it seems that it's more appropriate to use KC_ before the keycodes so that the handy aliases like MO() and others can be used directly in the keymap. However, this gives me numerous errors when compiling because it attempts to put an additional KC_ in front of each one. Simply omitting the KC_ doesn't actually solve anything, though, because it still attempts to create things like KC_MO(1).

I tried using my existing TMK keymap with the only changes being using the QMK aliases (though still put in the keymap with FNxx instead of directly like MO(1) or F(2)). When I compiled and flashed that, however, none of my FNxx keys did anything.

[fredizzimo]

Good that you got it flashed. I have no idea why it doesn't work in Ubuntu though. Is it a real machine or a virtual one?

You are probably using your own KEYMAP macro, rather than the one defined in infinity_chibios.h.

When converting a TMK keyboard, you should also remove the keymap_key_to_keycode, and keymap_fn_to_action functions. Here's a link to the commit that fixed the TMK Infinity Keyboard for QMK compilation.

If that doesn't help, then I need to see your keymap to help you further, do you have it in Github?

[Petrosophia]

It's a real machine. It's running Ubuntu 14.04 LTS, for what that's worth. As long as I have a way to make it work, though, I'm not super concerned, even though it's really odd.

The version of my keymap that I intend(ed?) to use can be found here. I had a much more TMK-style one that I attempted as well, but like I said, the FNxx keys didn't do anything there.

As an aside, once I have my drop 3 Infinity figured out, I'll see what I can do as far as getting QMK going on my drop 4...

[Petrosophia]

I suppose I should have mentioned that the files I've got are consistent with that commit you linked, so that shouldn't be the issue.

[fredizzimo]

It looks like you should move those functions from the fn_actions array to the keymap itself. Take a look at the ergodox default keymap for example.

Yesterday, I submitted a pull request with some documentation changes related to this. But I still think the documentation could be a lot clearer regarding this.

[Petrosophia]

Even having done that (github version of my keymap has been updated), I'm still getting lots of errors regarding the KC_ prefix. I even tried removing that prefix from the keymap definitions in infinity_chibios.h, but that only led to different errors.

results.txt
results-kc.txt

results.txt has the errors with the KC_##Kxx definitions in infinity_chibios.h, and results-kc.txt is without that KC_ prefix in infinity_chibios.h. The first one still has some errors related to having functions in the keymap, though they were basically the same errors as with the F(x) format.

Why is having the aliases directly in the keymap better than having F(x) ones that reference them? I was really only using the F(x) ones to make the keymap file a little more readable, since longer functions makes the spacing weird.

[fredizzimo]

Ah, I see now. There's a problem in infinity_chibios.h

Those macros should be changed to not add KC_. That will break the included keymaps though, so they need to be changed as well.

After that change your keymap should work when everything is prefixed with KC_

Do you think you can do that?

[Petrosophia]

When you say the macros should be changed to not add KC_, you mean that the ones with KC_##Kxx should instead read ##Kxx? Because when I did that, I got what you see in results-kc.txt above.

Or do you mean that the entire second section of the keymap definition (i.e. the entire section including all of the KC_##Kxx) should be removed, leaving only the top section with the Kxx?

[fredizzimo]

That's almost correct.

But the ## is the join operator for macros, so that should be removed too. So the final format should be just Kxx. For examples look at the other keyboards header files. They are in the keyboard specific folder and named like keyboard_name.h.

[Petrosophia]

It now works flawlessly. Thank you so much for your time and patience! You're welcome to close this whenever you like; I figured I'd just leave it open until those changes get merged. Now time to test out my newer Infinity!

[fredizzimo]

I can't close this myself. But feel free to close it.

If you want to, you can send a pull request with the fixes, including ones for the included keyboard layouts. Otherwise I will do it in the near future.

[Petrosophia]

I'm still really new to using git (and a lot of this stuff in general), so if you don't see a pull request from me by the time you get around to doing it, just go ahead with yours. It might take me a bit to get all this figured out lol

[fredizzimo]

Ok, no problem 😄