The LCD screen gets corrupted after a while

[fredizzimo]

When you leave the keyboard on for a while, the graphics on the LCD screen can get corrupted.

I don't really know what's causing it, or what could be done to fix it, so ideas are welcome.

Do other people have the same problem?

[fredizzimo]

It seems like not even putting the keyboard to sleep will fix the issue. In fact it seems like the sleep command is ignored and the graphics is still shown on the LCD.

[bremoran]

I have the same issue. It starts with the LED backlight on the right half going dark, then the right LCD turns off. Finally, the LCD on the left half gets corrupted.

[fredizzimo]

I have not personally observed the LED backlight going dark. But @tthayer reported a similar issue when he was testing the LED support #5.

But that problem makes the issue even more strange, since the two has nothing to do with each other, and are handled in completely different parts of the code.

Typically memory corruptions could cause issues like this, but since both systems are handled at completely different places, I have a hard time figuring out what variables could get corrupted and how.

An SWD debugger would be really useful. At least I think it could be used, but it seems like it would use the same pins as the interconnect, so I would only be able to debug with only one half connected. But currently I don't have any, and I don't know which one to buy, and from where. So I guess I will have to use print based debugging.

[bremoran]

I'm working on getting a SWD debugger up and running. I was able to find a colleague who has a tagconnect and I have a debugger handy. I'm just working out the pin mapping from tagconnect to the debugger.

It looks like SWD_DIO and SWD_CLK are dedicated lines so there is no reason that debugging can't happen on both at the same time.

[seancaffery]

I'm seeing the LED backlight going dark on the right half, but not the corruption of the screen.

[fredizzimo]

@bremoran, yes you are right. I believe the trace port would be quite useful for debugging this problem though. But it's connected to tx0, which is used for the UART communication.

[bremoran]

Yes, if it's down to needing trace, that will be a problem, however, I am hoping to track the problem down with just SWD debugging.

[bremoran]

When the right-hand LCD backlight goes dark, lcd_backlight_color() is called with (hue=64 '@', saturation=176 '\260', intensity=255 '\377'), however, current_brightness is set to 0, so there is no backlight.

lcd_backlight_brightness() is only called once, which points to a memory corruption bug.

The actual point where current_brightness gets set to 0 is in a memcpy()

Here is the traceback:

#0  0x000033bc in memcpy ()
#1  0x00008f32 in transport_recv_frame (from=<optimized out>, 
    data=data@entry=0x1fffa225 <states+5> "\001", size=size@entry=20)
    at ./tmk_serial_link/serial_link/protocol/transport.c:89
#2  0x00008d24 in route_incoming_frame (link=<optimized out>, 
    data=0x1fffa225 <states+5> "\001", size=<optimized out>)
    at ./tmk_serial_link/serial_link/protocol/frame_router.c:44
#3  0x00008dea in validator_recv_frame (link=<optimized out>, 
    data=<optimized out>, size=<optimized out>)
    at ./tmk_serial_link/serial_link/protocol/frame_validator.c:112
#4  0x00008c26 in byte_stuffer_recv_byte (link=link@entry=0 '\000', 
    data=<optimized out>)
    at ./tmk_serial_link/serial_link/protocol/byte_stuffer.c:74
#5  0x00009146 in read_from_serial (driver=<optimized out>, 
    link=link@entry=0 '\000')
    at ./tmk_serial_link/serial_link/system/system.c:68
#6  0x00009196 in serialThread (arg=<optimized out>)
    at ./tmk_serial_link/serial_link/system/system.c:101
#7  0x000022aa in _port_thread_start ()

In my build, current-brightness exists at 0x1fff86e4

I'm still working out the exact conditions for the failure, but it appears to be a flaw in transport_recv_frame()

[fredizzimo]

Thanks a lot,

There's some seriously dangerous code there in the transport protocol, mostly because I'm used to relying on C++ and type safety. I also wanted to keep the system from allocating.

Anyway this information is probably enough for me to find the bug.

[bremoran]

The issue occurs for id == 2 with ptr == 0x1fff86d4. Not sure if that helps

[bremoran]

Let me know if you need more help with this and I'll take another look.

[fredizzimo]

I'm not able to look into the issue properly right now, since I'm at work.

One thing that might help, is the map file in the build folder, which should specify where all variables are in memory, as I might not get the same memory locations if I build the code locally. At least I think that's file, but it could also be in some other file in that folder.

[bremoran]

Ah, one other piece of information:

remote_objects[2] == 0x1fff8648 <remote_object_current_status> and ptr == 0x1fff86d4

This implies that it's something to do with

void * ptr = triple_buffer_begin_write_internal(obj->object_size, tb);

[bremoran]

I generally prefer arm-none-eabi-objdump. Anyway, here's the map file
ch.map.txt

[fredizzimo]

The pointer might not be exactly the same as the object pointer, since as the name implies, there's three different buffers, triple_buffer_begin_write_internal, is supposed to return a valid pointer to one of them.

So either it's not returning a wrong pointer, or the size is too big, so that it's writing over the buffer. It could also be some alignment issue, which causes the pointer to be slightly offset from the size that was allocated.