Need help with a possible UC8159 bwry variant tag

[krikkirk]

I'm experiencing difficulties getting a Newton Pro 6.0 tag to function correctly. The device features a 5.8/6.0 BWRY e-paper display. I tested the existing uc8159.cpp driver and it performed reasonably well, but it lacks yellow color support. After attempting multiple driver implementations with AI assistance, the results have been unsatisfactory. The best outcome I've achieved still exhibits issues such as:

Display splitting into quadrants with glitched sections
Single display regions with black color bleeding and fading effect.

Captures

spi_captures.zip

PCB

Another question: the capture displays two data transmissions without a corresponding command. While this might not be significant, I'm unsure how the SC would handle or interpret this.

Could someone please review the implementation and identify what might be going wrong? I'd appreciate any help.

[krikkirk]

Hi @stevew817, sorry to bother you , but when you get a chance, could you review this? I really appreciate your help.

[stevew817]

A cursory reading of the implementation you posted seems like it in no way conforms to the captured traces... Is that on purpose? Note that I'm not developing the nRF firmware, so there could be things I'm misreading.

The bleeding looks like a case of a seriously/dangerously misconfigured LUT - there shouldn't be a need for manually configuring LUTs on these displays, as their controllers have OTP from which the factory LUT is loaded automatically. The first image looks like an artifact of sending half-width BW/BR frames (as done on BWR displays) instead of a 2bpp full frame (as done on most BWRY controllers).

What about the BWR uc8159 driver works 'reasonably well'?

Another question: the capture displays two data transmissions without a corresponding command. While this might not be significant, I'm unsure how the SC would handle or interpret this.

Looking at the capture, this seems to be a display controller response to command 0x40, which would be the temperature sensor reading from the display. The SOC first sends 0x41 0x00 to configure the display to sample its internal temperature sensor with 0 offset, then issues command 0x40, waits until busy deasserts, and then pulses the SCK to get a response from the controller. 0x18 0xA0 could be interpreted as 24.5 degrees celsius (0x18 = 24, 0xA0 has upper two bits as 10 which would map to +0.5C according to e.g. an equivalent Jadard chip).

Are you sure this is actually a UC variant and not yet another Solum-commissioned custom driver?

[krikkirk]

@stevew817 Thank you for the comment and the explanation regarding the mysterious data.
I’m not sure which controller it uses, or if there are any tricks to identify it. Also, the chip has read protection enabled, so no stock user data.

The printing on the FPC says E219454. According to GxEPD2, this corresponds to a 5.65inch acep 7-color e-paper e-ink display module. However, when I tried the example on an ESP32 dev module, it didn't work at all.
If it were actually a 7-color display, I would expect glitches in colors other than just yellow and red.
It is more likely that E219454 is the identifier for the FPC used in these displays.

What about the BWR uc8159 driver works 'reasonably well'?

It refreshes like the stock firmware i.e., flashing yellow and red during the refresh and with no ghosting or glitches in the end. But, of course, only BWR is displayed.
I also tried the uc8179 driver, but it didn't work at all.

I probably messed up somewhere in the driver implementation. I’m going to start over in a few days and let you know how it goes.

[krikkirk]

I got the driver working without reading the temperature and use the command from the capture. It might not work at temperatures other than room temperature. I will update the branch later but the key is

[krikkirk]

Here is my implementation.
There are 3 issues:

1. No temperature sensor reading from the display. The config captured at RT is used
2. The current OPEL definition of 0x2cis used by other tag. New definition TBD
3. The tag likely to reboot if the dragged image is not 600*448, more likely when the image is larger than the value.

edit: one more problem
the tag will very frequently do a second refresh after the image is already displayed.

UART did not show logs related to the display refresh or why reboot is triggered. Not sure if there is an option to turn on extensive logging
Channel: 11 - LQI: 156 RSSI -54 Channel: 11 - LQI: 152 RSS I -54 Channel: 11 - LQI: 152 RSSI -54 SETTINGS: Updated settings in EEPROM executing comma nd 0 OEPL-BOOT BOOTED> 002A-COMPR MAC>9D963D776D0C0000 SETTINGS: Loaded from EEPROM voltage = 3258 Channel: 11 - LQI: 140 RSSI -58 Channel: 11 - LQI: 140 RSSI -58 Channel: 11 - LQI: 140 RSSI -58 Channel: 11 - LQI: 140 RSSI -58 SETTINGS: Updated settings in EEPROM