Cannot get nice!view to work after recent update

[ghostbuster91]

Hi,

I have a custom keyboard with a self made shield - https://github.com/ghostbuster91/Dilemma3x6_3-zmk This is a split keyboard equipped with nice!nanos & nice!views. More about the keyboard here.

Today I updated the firmware in the left half (master). Previous firmware version was from almost a year ago. I am using a fork of zmk which is fairly up-to-date: https://github.com/nickconway/zmk/

The keyboard used to work well so far with both displays.

The update didn't go smoothly as first the build failed with following errors:

/opt/zephyr-sdk-0.16.3/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd: zephyr/libzephyr.a(status.c.obj):/__w/Dilemma3x6_3-zmk/Dilemma3x6_3-zmk/zmk/app/boards/shields/nice_view/widgets/status.c:284: multiple definition of `widget_layer_status_mutex'; app/libapp.a(layer_status.c.obj):/__w/Dilemma3x6_3-zmk/Dilemma3x6_3-zmk/zmk/app/src/display/widgets/layer_status.c:51: first defined here
/opt/zephyr-sdk-0.16.3/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd: zephyr/libzephyr.a(status.c.obj):/__w/Dilemma3x6_3-zmk/Dilemma3x6_3-zmk/zmk/app/boards/shields/nice_view/widgets/status.c:284: multiple definition of `widget_layer_status_work'; app/libapp.a(layer_status.c.obj):/__w/Dilemma3x6_3-zmk/Dilemma3x6_3-zmk/zmk/app/src/display/widgets/layer_status.c:51: first defined here

At first, I decided to just comment out anything custom connected with the display and see if the build will pass (commit).

It did so I installed new firmware on the board. After that, I noticed that the display stopped working. It started to show some gibberish. I thought that maybe this is due to some misconfiguration on my side.

I found this issue which mentions the same errors and applied the suggestion. This fixed the compilation so I uploaded new firmware on the board. However, the screen remained borked. I thought that it might be due to https://github.com/zmkfirmware/zmk/issues/1749

After this I decided to build the old firmware once again using the zmk revision from the day the of the last commit in my repository. That was 19 Jul, so I took f3110d1d1ea195725551b4c997c542a4003e1452 which is right before:

The build passed without any issues - https://github.com/ghostbuster91/Dilemma3x6_3-zmk/pull/4 and I uploaded it on the board. However the screen issue remains.

Below, photo of both halves, the right one with updated firmware and the left one with the original one.

1. Do you think that the display might have gotten irreversibly broken?
2. If so what could have caused that? If not, any ideas how to fix it?

[caksoylar]

I doubt your display is broken by flashing different firmwares. Just in case the setting got scrambled, I would try toggling external power off/on so that you can make sure it is on on both sides. Then wait a minute (so the setting is persisted to flash), and reset the controller. (Sometimes display doesn't boot up properly on ext. power on but it can boot after a reset.)

It looks like you figured out what happened: The nice!view got a custom status screen in the last year, and the .conf settings you used don't apply to them.

If I were you I wouldn't bother testing the old firmware. I'd flash the new one (if you want you can disable the custom screen https://github.com/zmkfirmware/zmk/issues/1273#issuecomment-1712938706 and keep your .conf settings) and test that. As an aside, you might want to use ZMK main along with https://github.com/dhruvinsh/zmk-tri-state module instead of nickconway's ZMK fork (which needs to be manually updated).

[ghostbuster91]

Then wait a minute (so the setting is persisted to flash)

What setting do you have in mind here?

Thanks for the suggestions. I tried restarting it on a battery and on ext_power. Still the issue persists :(

[caksoylar]

What setting do you have in mind here?

I mean the internally stored state of the external power toggle. When you use e.g. &ext_power EP_ON, the state gets saved to storage after one minute (to reduce flash wear on repeated uses).

I don't have other suggestions, but if you make a help post on the Discord maybe other folks can comment.

[ghostbuster91]

Got you. Thanks for your suggestions. I will look for more help on discord.

I am going to close the issue for now. If I get some new information that will be worth sharing I will post it here and we might then reopen.

[MalpenZibo]

Hi @ghostbuster91 have you found a solution? Because I have just installed a couple of nice view and I got the same results as on your screenshot!

[ghostbuster91]

Hi @MalpenZibo I didn't. But it seems that we can reopen the issue as there is definitely something wrong. I also tried flashing the other half recently with the newly built firmware with the same results.

[MalpenZibo]

Ok, thanks for the response. In my case I just discovered that the issue was a bad solder of the cs nice view PIN.

So no firmware issue in my case.

[nmunnich]

I'm going to re-close this, considering the current state of the issue. Feel free to re-open if you see a reason to do so, but I'm happy to write this off as a hardware error.

[ghostbuster91]

FYI, in case someone else runs into this issue - I finally found some time to sit down and investigate why my display stopped working.

After building the keyboard firmware locally, I inspected the generated DTS files and noticed that the cs-gpios pin, despite being set to 21 in my configuration, was ending up as 1 in the compiled output:

 rg -n "nice_view|cs-gpios|spi0" .build/dilemma_left+nice_view_adapter+nice_view-nice_nano_v2/zephyr/zephyr.dts    
17:             zephyr,display = &nice_view;
122:            spi0: nice_view_spi: spi@40003000 {
131:                    cs-gpios = < &pro_micro 0x1 0x0 >;
132:                    pinctrl-0 = < &spi0_default >;
133:                    pinctrl-1 = < &spi0_sleep >;
135:                    nice_view: ls0xx@0 {
548:            spi0_default: spi0_default {
554:            spi0_sleep: spi0_sleep {

Here is relevant part from my configuration:

nice_view_spi: &spi0 {
    cs-gpios = <&pro_micro 21 GPIO_ACTIVE_HIGH>;
};

This clearly showed that my configuration was being overridden by defaults. After digging a bit deeper, I realized the problem was caused by the order of shield definitions in my build.yaml file.

I originally had:

---
include:
  - board: nice_nano_v2
    shield: nice_view_adapter nice_view dilemma_left
  - board: nice_nano_v2
    shield: nice_view_adapter nice_view dilemma_right
  - board: nice_nano_v2
    shield: settings_reset

After changing it to:

---
include:
  - board: nice_nano_v2
    shield: nice_view_adapter nice_view dilemma_left
  - board: nice_nano_v2
    shield: nice_view_adapter nice_view dilemma_right
  - board: nice_nano_v2
    shield: settings_reset

...the display started working again.

I got the screen got back to working.

I'm not entirely sure whether the display used to work earlier because I temporarily had a different shield order (I don’t see such a version in Git), or if something changed in ZMK that modified how overlays are evaluated.

Either way, I think the documentation could be updated - the current example shows the keyboard shield first, which can lead to this issue. For instance, the docs currently use something like:

include:
  - board: nice_nano_v2
    shield: lily58_left nice_view_adapter nice_view
  - board: nice_nano_v2
    shield: lily58_right nice_view_adapter nice_view

but I think it should be:

include:
  - board: nice_nano_v2
    shield: nice_view_adapter nice_view lily58_left
  - board: nice_nano_v2
    shield: nice_view_adapter nice_view lily58_right

This small ordering detail can silently break the SPI CS override for nice!view users.

[lesshonor]

but I think it should be:

include:
  - board: nice_nano_v2
    shield: nice_view_adapter nice_view lily58_left
  - board: nice_nano_v2
    shield: nice_view_adapter nice_view lily58_right

It would be a good idea to create a branch in your repository with these proposed changes in order to test them out.

I would suggest overriding the CS pin in your keymap.

[ghostbuster91]

It would be a good idea to create a branch in your repository with these proposed changes in order to test them out.

I did that before writing in here. It works. https://github.com/ghostbuster91/Dilemma3x6_3-zmk/blob/nix2/build.yaml#L15

I would suggest overriding the CS pin in your keymap.

While this solution would probably work I am not a fan of it because I think that such configuration belongs more to the shield definition than to the keymap.

[Genteure]

such configuration belongs more to the shield definition

I agree. But then the "semantically correct" way would be defining nice_view_spi in the shield definition without using nice_view_adapter since your shield doesn't have a SSD1306 OLED screen. https://github.com/zmkfirmware/zmk/tree/v0.3-branch/app/boards/shields/nice_view_adapter

[lesshonor]

I did that before writing in here. It works. https://github.com/ghostbuster91/Dilemma3x6_3-zmk/blob/nix2/build.yaml#L15

I meant explicitly with the lily58_left and lily58_right shield names. Test exactly what you quoted, since that is the change you are proposing for the documentation.