NerD60 - TMK Conversion / It works !!!

[DanielT]

Ok, now things are a bit more clear to me I will go vanilla first and after I get the hang of it I can go with custom bootloaders.

Now about the fuses and locks, what should I do at a minimum? I have started to read about this as I really want to understand how it all works

[mohitgarg]

Here's are a couple of tested LUFA bootloaders.

As flabberghast said, you just need access to the RESET and GND pins to put the device in bootloader mode.

If you are using LUFA DFU, you'll need to install the drivers,
wiki/AVR-Keyboard
wiki/Flip-USB
http://www.atmel.com/tools/FLIP.aspx

If you use the Mass Storage Bootloader, you'll need either compile your firmware as bin or convert it to bin using avr-objcopy (avr-objcopy -I ihex -O binary -R .eeprom -R .fuse -R .lock -R .signature input.hex output.bin)

[mohitgarg]

Ok, now things are a bit more clear to me I will go vanilla first and after I get the hang of it I can go with custom bootloaders.

Now about the fuses and locks, what should I do at a minimum? I have started to read about this as I really want to understand how it all works

You can check the Atmega32u4 documentation, page 353, 28.1 and 28.2 for what the different fuse bits and lock bits are used for.

This is what I use:

Code: Select all

EFUSE:1111 0011 = F3
           ^
		   This is HWBE pin, 0 means enabled (If HWB pin low, start bootloader)
		   
HFUSE:1101 1		00		1 = DB
					^^		^
These are for boot size		This is BOOTRST pin, 1 means disabled (Don't run bootloader on start)
00 - 4k
01 - 2k
10 - 1k
11 - 512

LFUSE:1111 1111 = FF

LOCK: 1110 1111

[DanielT]

OK, I'll have to read more on that, thanks for the info
If I make this work I will write a proper procedure

[DanielT]

OK, I\m fed up with this PCB, wrote the bootloader looked like success, read the hex and this time wasn't empty but the keyboard still the same GON Firmware. Updated the GON firmware because I wanted to know at least that the board has a clean firmware and now it works fine in BIOS but after the system comes up I have to unplug and plug again the keyboard in order to work.

[DanielT]

I think the problem is related to the message I get, invalid signature 0x000000 or 0xffffff . I have checked the wiring and should be OK. I have read that some chips need extra power, just the power from the ISP is not enough. Maybe the keyboard should be plugged in ? Or should I get a decent ISP programmer like USBasp ?

[flabbergast]

You should be able to get the correct signature somehow; if it remains 0xFFFFFF then there's something wrong (I thought it's because of the lock bits, but I may be wrong about this - I've never used lockbits. I'll go and play with some attinys now and report

Power: you can also power the board via USB, in which case you have to disconnect the power to the board from the teensy. I.e. you should always have only one source of power on each board (different boards can have different sources, e.g. now you'd have one source for the teensy and one source for the KB), and all the grounds must be connected to each other.

[flabbergast]

OK, having played with an attiny, here are the findings:
- I can always read the correct signature, even when the chip is locked (so your setup is not working properly yet)
- when the chip is locked, reading of the flash will succeed, but the resulting file will be blank
- erasing the chip ('-e') will clear the lock bits
- you can read the lock bits with '-U lock:r:-:h'

[DanielT]

Thanks for this info man From what I have read the invalid signature is almost everytime caused by wiring problems. So I have decided to get me some decent wires with nice endings I can securely insert in the PCB holes, I have also ordered an USBasp programmer, I wanted to get one anyway so why not now. If I'm starting to play with this I should at least use proper tools
So as soon as I get everything I'll start over again. This is personal now

[DanielT]

So after the first attempts I have reached to some conclusions.
1. If you don't have a clue about AVR programming and how things work read about it before you start anything.
2. If you don't have any experience with ISP programming don't try and MacGyver your way in, any improvisation just adds more error sources and everything becomes a nightmare (I did that and having no experience I just don't know where the problem is)
3. If you are a beginner like me buy the right tools, so I have ordered a decent USBasp , some cables to connect without any problems to the terminals.

I hope that after I have everything I will be able to concentrate on the actual programming and not on debugging the improvised tools I was using.
So until I get all the tools I'm going to do some reading on this subject to better understand what I want to do.

[mohitgarg]

Not too sure about number 2.

I was able to program the Arduino as ISP on my Teensy and use it successfully to flash a new bootloader.

[DanielT]

You have more experience than I do At this point I want to make sure that I'm using the right tools, because all the things I have tried led me to the same 0x000000 problem, and spending 14$ on a decent programmer is not that much considering that I'm trying to mod a quite expensive board

I have 2 NerD60 boards and I want to put TMK on both of them. The ISP thingy I bought is this one http://www.ebay.de/itm/-/322073128124 , and I think it's a good investment, I chose the original one and not a clone so it should be OK.

[mohitgarg]

You have more experience than I do At this point I want to make sure that I'm using the right tools, because all the things I have tried led me to the same 0x000000 problem, and spending 14$ on a decent programmer is not that much considering that I'm trying to mod a quite expensive board

Quite the contrary, it was my first time using ISP (Hell, it was the first time I heard of ISP) and the Arduino as ISP does seem to work well based on the forums.

If you don't mind me asking, can you share the pins you connected from the Teensy to the board, photos of both sides would help. How long before you get your programmer?

[DanielT]

I don't have photos, I'm at work right now. The pins I have used are GND,VCC, PB0 (SS) for RST,PB1 for SCLCK,PB2 for MOSI and PB3 for MISO . I have checked the connections and there were no problems.
I should get the programmer next week as I have ordered it from Europe, and for the moment I don't have time anyway for more experimenting.
I really want to make this work because the NerD firmware is buggy as hell, with the current firmware I get keyboard BIOS error and have to first boot the computer and plug the keyboard afterwards, tried a newer firmware and the BIOS error is gone but after the OS comes up the keyboard is no longer seen and I have to unplug and plug it in again ... And this behavior is the same across multiple computers, DELL, Lenovo, HP, Linux/Windows . On MAC it's even worst. And the keyboard works decent only in 6KRO in NKRO the behavior is more erratic... With TMK I don't have such issues, and for reprogramming I'm not stuck with a Windows GUI and .NET like on GON firmware.
It's a shame, because the hardware is a beauty.

[mohitgarg]

That sounds right. Best to wait for the programmer and then dive into this again.

[DanielT]

I'll do just that Each time I'm starting to work on this I'm getting closer and closer so maybe the next time it will be a success

[beltet]

Very interesting thread! I maybe will try to do the same later on. But as my GON is my main atm I dont want to ruin it .
But will follow and see what your findings is.

[DanielT]

I have more boards I can use, so I can take a small risk, I really don't want to break this board because I love it. I hope to be able to make this conversion and make also a nice procedure easy to follow

[DanielT]

Today I have received the UASBasp programmer maybe in the weekend I'll have time to make a new attempt

[mohitgarg]

Waiting to hear how it goes

[Stabilized]

I have been thinking about doing this too, as my NerD 60 has a bit of lag on Mac for whatever reason.

If you end up with a good result I think I am going to try this on mine.

[DanielT]

That lag on MAC is something I have noticed too when I had a MAC, it has something to do with the firmware. I had also some crashes on MAC cause by the keyboard. If this works it will be very nice And if it works I will make a step by step procedure with photos and everything. I'm not rushing this because I don't want to break something.

[Stabilized]

That would be awesome! I would be really interested if you did

It sucks for me as I love the keyboard but I use a Mac most of the time, so I end up choosing not to use it.

[DanielT]

I know, I have problems also in BIOS and in Linux with the board, I want to enjoy it without the need to unplug it and stuff like that.

[DanielT]

Ok, with the UASBasp programmer I am able to read the flash and to write a new bootloader:

Code: Select all

dtraila@liz:~/Software/Teensy$ avrdude -p m32u4  -c usbasp -U flash:w:ATMega32U4-usbdevice_dfu-1_0_0.hex -P /dev/USBasp 

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9587
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "ATMega32U4-usbdevice_dfu-1_0_0.hex"
avrdude: input file ATMega32U4-usbdevice_dfu-1_0_0.hex auto detected as Intel Hex
avrdude: writing flash (32768 bytes):

Writing | ################################################## | 100% 0.00s

avrdude: 32768 bytes of flash written
avrdude: verifying flash memory against ATMega32U4-usbdevice_dfu-1_0_0.hex:
avrdude: load data flash data from input file ATMega32U4-usbdevice_dfu-1_0_0.hex:
avrdude: input file ATMega32U4-usbdevice_dfu-1_0_0.hex auto detected as Intel Hex
avrdude: input file ATMega32U4-usbdevice_dfu-1_0_0.hex contains 32768 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 32768 bytes of flash verified

avrdude: safemode: Fuses OK (E:C3, H:D8, L:DF)

avrdude done.  Thank you.

I can read without any problems :

Code: Select all

dtraila@liz:~/Software/Teensy$ avrdude -p m32u4  -c usbasp -U flash:w:ATMega32U4-usbdevice_dfu-1_0_0.hex -P /dev/USBasp 

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9587
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "ATMega32U4-usbdevice_dfu-1_0_0.hex"
avrdude: input file ATMega32U4-usbdevice_dfu-1_0_0.hex auto detected as Intel Hex
avrdude: writing flash (32768 bytes):

Writing | ################################################## | 100% 0.00s

avrdude: 32768 bytes of flash written
avrdude: verifying flash memory against ATMega32U4-usbdevice_dfu-1_0_0.hex:
avrdude: load data flash data from input file ATMega32U4-usbdevice_dfu-1_0_0.hex:
avrdude: input file ATMega32U4-usbdevice_dfu-1_0_0.hex auto detected as Intel Hex
avrdude: input file ATMega32U4-usbdevice_dfu-1_0_0.hex contains 32768 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 32768 bytes of flash verified

avrdude: safemode: Fuses OK (E:C3, H:D8, L:DF)

avrdude done.  Thank you.

So everybody would think I'm ready for TMK.... well not quite
I plug in the keyboard and it is very clear that the controller is in DFU mode :

Code: Select all

[ 5564.032173] usb 1-1: USB disconnect, device number 14
[ 5565.960092] usb 1-1: new full-speed USB device number 15 using uhci_hcd
[ 5566.141092] usb 1-1: New USB device found, idVendor=03eb, idProduct=2ff4
[ 5566.141095] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 5566.141097] usb 1-1: Product: ATm32U4DFU
[ 5566.141099] usb 1-1: Manufacturer: ATMEL
[ 5566.141100] usb 1-1: SerialNumber: 1.0.0

So it should be ok right? well it's not, I have compiled the TMK firmware, the default stuff nothing fancy, tried to write the firmware, was again ok, no problem and nothing... the controller is still in DFU mode

[DanielT]

Ok, now I'm getting closer :d If I do a "Start application" from FLIP I the keyboard starts working, the only problem is after I unplug it and plug it back it goes in DFU mode again. Crap I have to figure out how to get pass this shit anyway it's better

Code: Select all

[  596.236048] usb 1-1: new full-speed USB device number 7 using uhci_hcd
[  596.421099] usb 1-1: New USB device found, idVendor=feed, idProduct=6060
[  596.421102] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  596.421104] usb 1-1: Product: NerD
[  596.421106] usb 1-1: Manufacturer: GON
[  597.578507] input: GON NerD as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1:1.0/0003:FEED:6060.000C/input/input25
[  597.578790] hid-generic 0003:FEED:6060.000C: input,hidraw0: USB HID v1.11 Keyboard [GON NerD] on usb-0000:00:1a.0-1/input0
[  597.583386] input: GON NerD as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1:1.1/0003:FEED:6060.000D/input/input26
[  597.583611] hid-generic 0003:FEED:6060.000D: input,hidraw1: USB HID v1.11 Mouse [GON NerD] on usb-0000:00:1a.0-1/input1
[  597.589211] input: GON NerD as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1:1.2/0003:FEED:6060.000E/input/input27
[  597.589408] hid-generic 0003:FEED:6060.000E: input,hidraw5: USB HID v1.11 Device [GON NerD] on usb-0000:00:1a.0-1/input2
[  597.594226] hid-generic 0003:FEED:6060.000F: hiddev0,hidraw6: USB HID v1.11 Device [GON NerD] on usb-0000:00:1a.0-1/input3

[DanielT]

Ans also backlight works yeiiii Now to get pass the bootloader thingy and I'm a happy camper. After that I need to make my own keymap, but that is easy I'm going somewhere with this.

[scottc]

I remember flabbergast mentioning at one point that the bootloader needs to know which address to jump to to start executing firmware code once set-up has finished. I wonder if that's the part you're missing.

Fantastic work getting this far! This is very exciting.

[DanielT]

Maybe that's what I'm missing, but I really have no clue, I'm still stoked I made it this far

[DanielT]

I think this is the problem (it's from DT Wiki, very nice article ):

When an ATMEL chip powers up or resets, it checks its fuses, and if they say that it should start with a bootloader (rather than normal firmware at the beginning of the flash), it starts executing the code near the end of the flash memory - where the bootloader should reside. Now the bootloader somehow determines whether it should jump back to the "application code" at the beginning of the flash, or whether it should continue running.

So I have to read more about this part.Anyway I'm happy with the results so far. Flashing a new bootloader is really easy with UASasp and proper cables, it's a really good piece of hardware and when I bought it I chose the original product instead of a cheap clone because I think it's good to support such a cool project.