Screen freezing on the EVE_CFAF800480E1_050SC_A2 but not EVE_CFAF1024600B0_070SC_A1

[jwestes]

I'm seeing some strange behavior and I cannot figure out what is going on. When I compile the library for the CrystalFontz 5" touch screen, the splash screen of my application shows up just fine. The main page is then displayed properly as well. However, when I tap the toggle to turn the system on, the screen stops refreshing. I know the code is still running and the loop is continuing to send EVE commands to the screen. I can connect with a bluetooth app and manipulate the running parameters, and I see the log messages coming through in the serial monitor. As soon as I tap on the toggle to turn the system back off, the screen starts refreshing again.

However, when I compile the application/library for the CrystalFontz 7" screen, I do not see this same behavior. When I turn the system on, the screen continues to refresh normally. The only changes in my code for the different screens are locations and sizes of widgets on the screen. Other than that, it is the same code.

Is there a way to see what commands are being sent to the screen and validate they are correct? I have made several attempts to isolate the issue and at this point I am out of ideas.

[RudolphRiedel]

I am not sure that I got what your issue is. If you tap to turn the system off the screen starts refreshing?

Anyways, are you using the EVE_CFAF800480Ex_050SC_A2 profile or the EVE_CFAF800480E1_050SC_A2 profile and
have you tried to swap it?
This might be an issue with the touch controller.

Occasionally I get myself into a corner with a black screen staring back at me, for example with new hardware.
Then I have a look with the logic analyzer and start to put blocks of code in #if 0 / #endif statements to find out where things went wrong.

[jwestes]

Sorry, I guess I should be more specific. If I tap the toggle on the screen to enable automation in my program, the screen "freezes" and none of the commands I send to the screen have any impact on what is displayed. However, with an ESP_PROG attached, I can see my code running and commands being generated as I would expect. If I tap the toggle again to turn automation off, the screen starts reacting to my drawing commands again. It does not seem to be an issue with the touch controller. I didn't know if there was a way to log what commands were being sent or any other tools that could be used to figure out what is happening.

I do have to say, this screen itself is suspect. It was originally a newer production unit built last summer with the BT817. This is actually the one where we found the difference between the EVE_CFAF800480Ex_050SC_A2 profile and the EVE_CFAF800480E1_050SC_A2. However, the screen itself died a couple months ago. When I was at CrystalFontz last month, I took it in to show them and they had an "engineering only" screen they gave me as a replacement. I had to detach the screen from the BT817 board and put the new one on. It was not a difficult or technical process, but I have not seen this screen work since before that happened. Unfortunately, there has also been a ton of my code that has changed in that same timeframe, so I can't say which is causing the problem.

I guess I will try 2 things and hope one of them gets me unstuck. I will go back to the first check-in I have and see if that code runs on this screen or if it does the same thing. I will also see if CrystalFontz has another screen they can run my code on to see if it does the same thing this one does. I'm assuming there are no real tools or logging available to figure this out?

[jwestes]

I was just able to narrow the problem down to something in my code for sure. I took my first commit, built and ran it on the 5" screen and it worked fine. I then updated that build to the latest version of the library and it continues to work. I will go through my code removing components until I find the problem.

[jwestes]

I found it. I had a font set to 39 for one of the text widgets that is only visible when the system is turned on.

[RudolphRiedel]

Glad you found it!
39 is not a valid bitmap-handle though, these only go from 0 to 31.
The BITMAP_HANDLE macro uses & 0x1f but the widgets API somehow uses int16_t font - and negative values definately do not work.
I am looking at _Static_assert and perhaps I should increase the C-standard to C11.