Jump to content

nathanwiebe

Members
  • Content Count

    6
  • Joined

  • Last visited

About nathanwiebe

  • Rank
    Newbie
  1. The gdisp_lld_blit_area() function is broken in a few ways, both to do with blits whose source X coordinate is non-zero: 1. The following line is intended to compute the source array for the blit operation, but doesn't take into account the source offset. buffer += g->p.x2*g->p.y1; It should be changed to something like: buffer += g->p.x2 * g->p.y1 + g->p.x1; 2. Near the bottom of the function, the following code is intended to detect if a rotation has been done (thereby changing the buffer variable from the pixmap base buffer to a freshly allocated, rotated
  2. Sounds great! I may be looking in the wrong place, but the only changelog I can find only includes changes up until v2.7. is there a newer changelog by chance with a basic overview of v2.8 changes?
  3. I am using what I think is the stock 2.7.0 release, rather than follow the repo, so likely I am using an old FreeRTOS port. In any case, it is a subtle bug, but not too hard to search for. Searching for the text portENTER_CRITCAL and taskENTER_CRITICAL will find all critical sections in the FreeRTOS/uGFX interface code, and it should be checked that there is no FreeRTOS API usage (even non-blocking calls such as a binary semaphore push/give - see the note on the FreeRTOS critical section documentation) within the critical sections. In the version I have (stock 2.7.0 I think), gos_freertos.c
  4. Good news! The bug has been fixed. Unfortunately I am able to offer less clarity on the exact solution that I had hoped. As I mentioned, my specific display glitch started 26:49 after boot, continued for 67 seconds, and repeated every 71 minutes. I believe the root cause to have been related to something thrashing and eating up too much SDRAM bandwidth. I hoped to narrow down precisely which lines of code this was, however this did not happen before the bug was solved another way. FreeRTOS on CortexM parts forbids making any OS API call from within a critical section. Probably 99.99% of
  5. A huge thanks for all the helpful suggestions. I will look into all of these things, although I have to apologize for being slow to look into this because of other project demands. For now, here is a quick update on my investigation: As I mentioned, it takes 27 minutes to get the glitch to happen, and it only lasts 67 seconds, so gathering info is extremely inefficient. I have stepped through various parts of the code during the glitch and nothing sticks out. I can see some flickers as I single-step, but haven't correlated it to a particular area of code or RTOS thread priority level.
  6. I was wondering if anyone has any hints on how I can troubleshoot a problem I am having. I am a paid customer with a commercial license and my first design using uGFX is almost production-ready, but there is a glitch in the software that is holding me up. I am using an STM32F777 processor with a 800x480 LCD with the frame buffer located in external SDRAM. I have a second frame buffer that I actually draw to, and I use the hardware blit/region copy functionality of the STM32's DMA2D to draw updates to the live frame buffer. As far as uGFX is concerned, my code is very closely based on the S
×
×
  • Create New...