Settings not persisted to EEPROM for Teensy 3.6

[ameyp]

I've been using the set_single_persistent_default_layer function to switch base layers but the changes aren't persisted to EEPROM. I've also wired up a small LED strip and my understanding is that changes to RGB lights are persisted to EEPROM by QMK, but that's not working either. I believe QMK doesn't understand how to use the Teensy 3.6's EEPROM.

[stapelberg]

Thanks for filing this.

Your guess that QMK doesn’t understand how to use the Teensy 3.6 EEPROM sounds the most likely to me, too.

I’ll try and take a look at what would need to be changed in the next few days as time permits.

[stapelberg]

Can you update your branch so that commit https://github.com/kinx-project/qmk_firmware/commit/1f84198750751dded9e12626b725df94aa33c875 is included and try again?

For me, this looks like it might be enough to make the EEPROM work, but I have only done a very quick test.

[ameyp]

For me it made the controller not boot up. None of the keys were responding, and even the ON led on the teensy was off.

[stapelberg]

Can you try it with these changes please (changing CPU speed from 180MHz to 120MHz)?

modified   keyboards/kinesis/kint36/mcuconf.h
@@ -28,12 +28,12 @@

 /* PEE mode - 180 MHz system clock driving by 16 MHz xtal */
 #define KINETIS_MCG_MODE KINETIS_MCG_MODE_PEE
-#define KINETIS_PLLCLK_FREQUENCY 180000000UL  // 180 MHz (HSRUN)
-//#define KINETIS_PLLCLK_FREQUENCY 120000000UL  // 120 MHz (RUN)
+//#define KINETIS_PLLCLK_FREQUENCY 180000000UL  // 180 MHz (HSRUN)
+#define KINETIS_PLLCLK_FREQUENCY 120000000UL  // 120 MHz (RUN)
 #define KINETIS_SYSCLK_FREQUENCY KINETIS_PLLCLK_FREQUENCY
 #define KINETIS_BUSCLK_FREQUENCY 60000000UL
-#define KINETIS_FLASHCLK_FREQUENCY 28000000UL  // 28 MHz (HSRUN)
-//#define KINETIS_FLASHCLK_FREQUENCY 24000000UL  // 24 MHz (RUN)
+//#define KINETIS_FLASHCLK_FREQUENCY 28000000UL  // 28 MHz (HSRUN)
+#define KINETIS_FLASHCLK_FREQUENCY 24000000UL  // 24 MHz (RUN)

 #if KINETIS_PLLCLK_FREQUENCY == 180000000UL
 #    define KINETIS_CLKDIV1_OUTDIV1 1  // -> 0

[ameyp]

Tried with those changes, same behavior. Are there any debug prints I can provide that might help you see what the MCU is doing?

[stapelberg]

Not that I know of :-/

One thing you can try is whether the example EEPROM programs that come with https://www.pjrc.com/teensy/td_download.html work on your device. Specifically eeprom_put and eeprom_get.

Maybe one needs to run these first before the EEPROM starts working? Worth a try.

[ameyp]

Tried running both examples, both passed and I saw success prints in the serial monitor after the _get sample. Also it seems to have changed something in my teensy: now when I flash a firmware built with this commit, the keyboard boots up and keys work. However, EEPROM still doesn't seem to be working at either frequency (layout isn't persisted across reboots) and some other funkiness happens, e.g. my backspace keycode is sent as a \ instead.

[stapelberg]

Also it seems to have changed something in my teensy

Thanks for confirming. I have read that EEPROM partitioning might be a step that leaves behind a persistent change, but will need to read up on what exactly that means for us here.

However, EEPROM still doesn't seem to be working at either frequency (layout isn't persisted across reboots

I wonder if this means that writing to the EEPROM doesn’t work yet, or if it’s something else entirely.

some other funkiness happens, e.g. my backspace keycode is sent as a \ instead.

Weird! Not sure why that is yet.

[waitnextevent]

After reading the docs for the MK66FX1M0VMD18 and FlexMemory application notes, I've been wondering if it may make more sense in the context of the keyboard controller to use the FlexNVM module in the default D-Flash mode instead of partitioning it into EEE ("enhanced EEPROM") when servicing the QMK EEPROM r/w routines.

It's all the same flash memory; from what I gather applications in E-Flash mode are for very frequently changing data where the EEE state machine will spread out the memory's finite number of read/write cycles over a larger area (such as using 256k of of flash as a smaller 4k EEPROM block). When instead used in D-Flash mode, one can leverage the entire capacity of the chip and not have to partition it beyond the default (unless somebody has already partitioned their Teensy, at least). I doubt keyboard users will need the up to 100 million write cycles spec'd for the EEE config..

I'm looking to see if I can bring up the Via feature for QMK on the Teensy 3.6, which lets you update the keymap without having to recompile all the time (as the stock Kinesis fw nicely allows). Via also uses the QMK EEPROM abstractions and could benefit from having more memory available.

Seems to me the routines to write to EEPROM in QMK really mean "write to some sort of persistence on the chip" rather than "write to something the chip calls EEPROM literally", meaning the EEPROM r/w calls could equally be implemented againt D-Flash for the board.

Thoughts?

[stapelberg]

Thanks very much for investigating and weighing in!

What you write makes sense to me—any persistence should do, yes.

Please give your approach a try and share what you learn :)

[stapelberg]

I have pushed branch https://github.com/stapelberg/qmk_firmware/commits/kint36-eeprom which makes the EEPROM work.

In case anyone wants to try it out and confirm that it works for them, that’d be much appreciated!