Momentary random colors upon booting

[mondalaci]

When powering up the UHK, random key colors can be seen for a moment. This is slightly disturbing and should be avoided.

[kareltucek]

Looks like factory mode is partially broken since following commit:

commit 481698e35f4196620a6884f764cbeaddf61a7e4d
Author: László Monda <laci@monda.hu>
Date:   Wed Feb 22 10:45:21 2023 +0100

    Put CurrentKeymap into the .data2 section because it wouldn't fit into .data1 with the RGB values included.

Scenario 1:

• Make config Validation fail (e.g., by flashing incompatible UserConfig), or manually set IsFactoryResetModeEnabled = true;
• Powercycle UHK.
• Observe that factory mode does not work. (Segment display reads FTY, backlight shows random colors, key taps produce no characters on screen)
• Press the factory reset button.
• Observe that behavior has not changed.

Scenario 2:

• Let your UHK load valid UserConfig.
• Press the factory reset button.
• Observe that factory mode works fine now contains the keymap from UserConfig that was active before reset.

Scenario 3:

• manually set IsFactoryResetModeEnabled = true;
• run make flash. (UHK restarts without powercycling and goes into factory mode.)
• Observe that factory mode works fine.
• Press the factory reset button.
• Observe that factory mode still works fine.
• Powercycle UHK.
• Observe that factory mode does not work.

---

@mondalaci does this ring any bells?

Is there anything special about how the data2 segment is initialized?

[mondalaci]

This doesn't ring a bell to me.

If there's anything special about the data2 segment, the https://community.nxp.com/ forum may be able to help.

Any further questions or findings, please do let me know.

[kareltucek]

More observations:

• I have been wrong when claiming that FTY works fine in some cases. In practice, last loaded keymap seems to remain loaded in memory. So it seems that the data2 segment never gets initialized, with one exception:
• Data2 segment seems to be initialized fine during the first boot after flashing. (Why should this be? What does this signify?)

[mondalaci]

Chances are data(2) segment(s) are uninitialized by default for performance reasons and they should be explicitly initialized when required.

[kareltucek]

No luck with a nxp inquiry... ( https://community.nxp.com/t5/Kinetis-Microcontrollers/m-data-2-not-initialized/m-p/1785711 )

I guess it is time for the suggested workaround of initializing it explicitly ourselves?

[mondalaci]

Let's ask our NXP contact before using the workaround. I'll provide his contact via email very soon.

It's worth mentioning that the part number of the MCU is MK22FN512VLH12. The K22P121M120SF7 is some sort of identifier in the datasheet that covers multiple MCUs of the same kind.

[kareltucek]

I think I have a working version, thanks to bobpaddock's today reply. It edits lib/KSDK_2.0_MK22FN512xxx12/devices/MK22F51212/gcc/startup_MK22F51212.S. Should I post a PR into the UHK submodule repository, or should I create a copy of that file directly in firmware repository?

[mondalaci]

The former should be the correct way if the fix belongs to a file in the KSDK repo.