ugfx/drivers/gdisp/SSD1322/driver.mk missing

[AnSc]

Hi,

I currently try to get my custom board up and running with a SSD1322 based OLED.

However, when I tried to build the code I got this warning:

ugfx/drivers/gdisp/SSD1322/driver.mk: No such file or directory

And indeed it was missing.

Version of ugfx: 2.9

I'm using the current version of Chibios (21.11) as a basis and after creating the .mk file I get now this error:

./ugfx/src/gos/gos_chibios.c:15:3: error: #error "GOS: Unsupported version of ChibiOS"

from this line: 

#if CH_KERNEL_MAJOR < 2 || CH_KERNEL_MAJOR > 5

after changing the max kernel version to ">50" it compiles but throws some warnings which seem to relate to the OS porting:

cast between incompatible function types from 'gThreadreturn (*)(void *)' {aka 'long int (*)(void *)'} to 'void (*)(void *)' [-Wcast-function-type]    gos_chibios.c    /RT_HPS_STM32F103/ugfx/src/gos    line 185    C/C++ Problem
cast between incompatible function types from 'gThreadreturn (*)(void *)' {aka 'long int (*)(void *)'} to 'void (*)(void *)' [-Wcast-function-type]    gos_chibios.c    /RT_HPS_STM32F103/ugfx/src/gos    line 192    C/C++ Problem

and some additional warnings:

duplicate 'const' declaration specifier [-Wduplicate-decl-specifier]    gdisp.c    /RT_HPS_STM32F103/ugfx/src/gdisp    line 586    C/C++ Problem
duplicate 'const' declaration specifier [-Wduplicate-decl-specifier]    gdisp_driver.h    /RT_HPS_STM32F103/ugfx/src/gdisp    line 735    C/C++ Problem
duplicate 'const' declaration specifier [-Wduplicate-decl-specifier]    gdriver.h    /RT_HPS_STM32F103/ugfx/src/gdriver    line 90    C/C++ Problem

But I'm new to working on STM23 and also new to uGFX so I'm not sure about the consequences of all these warnings.

My small application seems to start but no graphics output occurs. The code also seems to go to a halt during initialization "gfxInit();" of the display. When I do start the initialization in the main() it freezes after reset. When I put it in a thread I see the other threads starting (setting LEDs) and then freezing.

I would have expected from the comments in the code that some uGFX logo should display during initialization.

I'm currently unable to debug. My debug probe does not work correctly (no idea why this happens from time to time).

If I use a smallish self written function that only sends some random data to the display there is an output, althoug nothing meaningful. Therefore, the hardware is fine.

Are there any hints how to setup this correctly? I did find this thread but I'm not sure what to use of this for a minimum setup for initial testing if it works at all: 

Thanks for reading. :)

[AnSc]

My debugger worked again, so I could step through the initialization.

at this point it stops:

uGFX init gdisp_lld_SSD1322.c
[code] *ram &= ~xybits(x, y, LLDCOLOR_MASK()); [/code]
        
Debugger says:

[code] ram    gU8 *    0x20005027 <error: Cannot access memory at address 0x20005027> [/code]

and then Chibios stops with _unhandled_exception

Is this a problem with uGFX or Chibios? Any ideas?

[Joel Bodenmann]

Hello & Welcome to the µGFX community!

 

17 hours ago, AnSc said:

I'm using the current version of Chibios (21.11)

Honestly didn't yet get time to test with ChibiOS 21 but ChibiOS 20 support was added a few months ago. You might want to consider using the master  branch of the official µGFX repository: https://git.ugfx.io/ugfx/ugfx

 

17 hours ago, AnSc said:

ugfx/drivers/gdisp/SSD1322/driver.mk: No such file or directory

That appears to be a "bug". That driver is indeed missing the driver.mk file.
I can´t test this right now but the driver.mk file should be as simple as:
 

GFXINC += $(GFXLIB)/drivers/gdisp/SSD1322
GFXSRC += $(GFXLIB)/drivers/gdisp/SSD1322/gdisp_lld_SSD1322.c

Would be awesome if you could let us now if that worked out so we can patch the driver (adding the missing file).

 

17 hours ago, AnSc said:

and some additional warnings:

That's actually mishandling of the C standard by the compiler you're using (I assume it's GCC). This was something that has been going on for years. You can find some discussions of that online (and also on this forum). We eventually caved in. This was also patches in the master  branch of the official µGFX git repo.

 

 

16 hours ago, AnSc said:

at this point it stops:

uGFX init gdisp_lld_SSD1322.c
[code] *ram &= ~xybits(x, y, LLDCOLOR_MASK()); [/code]
        
Debugger says:

[code] ram    gU8 *    0x20005027 <error: Cannot access memory at address 0x20005027> [/code]

First of all: Can you please provide more information regarding your setup (exact STM32 MCU that you're using, which compiler etc)? Please also share (as attachments) your gfxconf.h and your board_SSD1322.h.

The SSD1322 driver uses the framebuffer model. As such, it needs to allocate a buffer large enough to serve as a framebuffer. This happens at line 69 of the driver. gfxAlloc() is used to allocate memory. The first thing you should check is whether the framebuffer allocation was successful. The driver would fail to initialize if the underlying system couldn't provide the memory needed but we have to start somewhere plus you'll need to know the framebuffer address for the next step below.

The fact that your debugger cannot access memory at that location as well as your "crash" happening when accessing that framebuffer memory might indicate that it is located in an inaccessible memory section/area. To further dive into this, we really need to know the exact type of STM32 MCU you're using.
The datasheet/reference-manual contains the memory map which tells you in which memory section your framebuffer got allocated. These days, microcontrollers got rather complex. They contain a lot of different memory sections with different accountabilities, policies and so on. It's not unlikely that your framebuffer got allocated in a memory section that cannot be accessed the required way.
We can continue looking into this after you provided more detailed information.
 

[AnSc]

Thanks for your detailed answer. I'm traveling for a few days but will get back to this starting next week.

As for the .mk file. I did create one from an example of the other drivers. But can't currently access it to check for its content. But it was as simple as two lines of code.

The MCU is a STM32F103 but I need to check the exact model. Should be a 128k type with 20 k RAM.

[Joel Bodenmann]

Just get back to this whenever it fits you. We'll be right here 😉

[AnSc]

Hi again,

Had some time today to dig in.

Model of the controller is STM32F103RBT6 with 128K FLASH, 20KB RAM.

Compiler is GCC (using ChibiStudio).

I did clone the main repository and stumbled again over the missing driver.mk file.

I created one with the lines above, which led to a successful build without the problem with a "wrong" ChibiOS version.

I get warnings about "GOS_NEED_X_THREADS" is not defined and "GOS_NEED_X_HEAP" is not defined.

I also get many warnings about "GFX_MEM_LT64K" is not defined.

I would feel more comfortable if there was some documentation on the individual options so I knew how to rate these warnings.

The first two read to me as if they do not apply since I'm using ChibiOS.

The GFX_MEM_LT64K is not so clear to me. I set it to "GFXON" for now since I only have little RAM.

However, it still seems to crash.

My debugger still does not work reliably, so I don't know at what point it crashes.

But during my last debugging there was no error during the allocation of the memory but only when it tried to access it.

 

However, if I take these 20kB RAM and convert this to hex I end up with 0x5000 as the amount of bytes.

Therefore, 0x2000 4fff would be the last RAM address in my understanding.

If the frame buffer is set to 0x20005027, this would be behind the last available address.

Have I a problem with my understanding and calculations or does the OS or uGFX make some error here?

 

[Joel Bodenmann]

On 18/04/2022 at 16:57, AnSc said:

I did clone the main repository and stumbled again over the missing driver.mk file.

We'll add the missing driver.mk file in the next couple of days.

 

On 18/04/2022 at 16:57, AnSc said:

which led to a successful build without the problem with a "wrong" ChibiOS version.

Awesome!

 

On 18/04/2022 at 16:57, AnSc said:

I get warnings about "GOS_NEED_X_THREADS" is not defined and "GOS_NEED_X_HEAP" is not defined.

I also get many warnings about "GFX_MEM_LT64K" is not defined.

Can you please share your gfxconf.h? Just attach the bare file to your next post.
When using ChibiOS, those should not be needed. I do assume that you set GFX_USE_OS_CHIBIOS to GFXON?

 

On 18/04/2022 at 16:57, AnSc said:

I would feel more comfortable if there was some documentation on the individual options so I knew how to rate these warnings.

You can find some of them documented here: https://wiki.ugfx.io/index.php/Configuration
And for the rest there is the API documentation: https://api.ugfx.io
If there's anything missing in terms of documentation will will rectify that ASAP.

 

On 18/04/2022 at 16:57, AnSc said:

The first two read to me as if they do not apply since I'm using ChibiOS.

Exactly, so something seems wrong. The ChibiOS port is used heavily by DIYs and commercial customers. While that doesn't mean that there isn't any bug I do think that in this case it's more likely to be a configuration issue. Please share your config file(s) as mentioned above.
When changing options (eg. in the gfxconf.h) don't forget to do a proper clean build.

 

On 18/04/2022 at 16:57, AnSc said:

Have I a problem with my understanding and calculations or does the OS or uGFX make some error here?

When you're using the ChibiOS port, µGFX doesn't do anything memory related. All memory management related functions are mapped to the underlying ChibiOS system.

[AnSc]

This is my config file.

I'm currently running out of ideas how to proceed further. so any ideas are welcome.

gfxconf.h

[Joel Bodenmann]

I can't spot anything that would be deemed "obviously wrong" in your configuration file.

I'm mainly confused by this:

On 18/04/2022 at 16:57, AnSc said:

I get warnings about "GOS_NEED_X_THREADS" is not defined and "GOS_NEED_X_HEAP" is not defined.

This should only be the case if you use the raw32 port (GFX_USE_OS_RAW32). This doesn't appear to be the case based on your config file.
Is there any chance that you're overriding some config options directly from your build system?
Did you try to do a proper clean build? Because even if you'd set GFX_USE_OS_RAW32 elsewhere the compilation should fail due to the GFX_USE_OS_xxx being mutually exclusive.

Can you please do a proper clean build and share your entire build output log?
Alternatively, is this an open-source project with a public repo that we can access?

There's not much that can be wrong here. Both STM32 and ChibiOS are first-class citizens in the world of µGFX.

[AnSc]

Thanks for helping me.

I pushed my code to github: https://github.com/transistorgrab/RT_HPS_STM32F103

This is the output from a clean build:

17:20:48 **** Build of configuration Default for project RT_HPS_STM32F103 ****
make -j all 
Compiling crt0_v7m.S
Compiling vectors.S
Compiling chcoreasm.S
Compiling crt1.c
Compiling hal.c
Compiling hal_st.c
Compiling hal_buffers.c
Compiling hal_queues.c
Compiling hal_flash.c
Compiling hal_mmcsd.c
Compiling hal_adc.c
Compiling hal_gpt.c
Compiling hal_i2c.c
Compiling hal_pal.c
Compiling hal_pwm.c
Compiling hal_serial.c
Compiling hal_serial_usb.c
Compiling hal_spi.c
Compiling hal_usb.c
Compiling nvic.c
Compiling stm32_isr.c
Compiling hal_lld.c
Compiling hal_efl_lld.c
Compiling hal_adc_lld.c
Compiling stm32_dma.c
Compiling hal_pal_lld.c
Compiling hal_i2c_lld.c
Compiling hal_spi_v2_lld.c
Compiling hal_st_lld.c
Compiling hal_gpt_lld.c
Compiling hal_pwm_lld.c
Compiling hal_serial_lld.c
Compiling hal_usb_lld.c
Compiling board.c
Compiling osal.c
Compiling chsys.c
Compiling chrfcu.c
Compiling chdebug.c
Compiling chtrace.c
Compiling chvt.c
Compiling chschd.c
Compiling chinstances.c
Compiling chthreads.c
Compiling chtm.c
Compiling chregistry.c
Compiling chsem.c
Compiling chmtx.c
Compiling chcond.c
Compiling chevents.c
Compiling chmsg.c
Compiling chdynamic.c
Compiling chmboxes.c
Compiling chmemcore.c
Compiling chmemheaps.c
Compiling chmempools.c
Compiling chpipes.c
Compiling chobjcaches.c
Compiling chdelegates.c
Compiling chfactory.c
Compiling chcore.c
Compiling chprintf.c
Compiling chscanf.c
Compiling memstreams.c
Compiling nullstreams.c
Compiling bufstreams.c
Compiling gfx.c
Compiling gos_chibios.c
Compiling gos_freertos.c
Compiling gos_win32.c
Compiling gos_linux.c
Compiling gos_osx.c
Compiling gos_raw32.c
Compiling gos_ecos.c
Compiling gos_rawrtos.c
Compiling gos_arduino.c
Compiling gos_cmsis.c
Compiling gos_zephyr.c
Compiling gos_nios.c
Compiling gos_x_threads.c
Compiling gos_x_heap.c
Compiling gdriver.c
Compiling gqueue.c
./uGFX/src/gos/gos_x_threads.c:10:5: warning: "GOS_NEED_X_THREADS" is not defined, evaluates to 0 [-Wundef]
   10 | #if GOS_NEED_X_THREADS
      |     ^~~~~~~~~~~~~~~~~~
Compiling gdisp.c
Compiling gdisp_fonts.c
./uGFX/src/gos/gos_x_heap.c:10:5: warning: "GOS_NEED_X_HEAP" is not defined, evaluates to 0 [-Wundef]
   10 | #if GOS_NEED_X_HEAP
      |     ^~~~~~~~~~~~~~~
Compiling gdisp_pixmap.c
Compiling gdisp_image.c
Compiling gdisp_image_native.c
Compiling gdisp_image_gif.c
Compiling gdisp_image_bmp.c
Compiling gdisp_image_jpg.c
Compiling gdisp_image_png.c
Compiling mf_encoding.c
Compiling mf_font.c
Compiling mf_justify.c
Compiling mf_kerning.c
Compiling mf_rlefont.c
Compiling mf_bwfont.c
Compiling mf_scaledfont.c
Compiling mf_wordwrap.c
Compiling gevent.c
Compiling gtimer.c
Compiling gwin.c
Compiling gwin_widget.c
Compiling gwin_wm.c
Compiling gwin_console.c
Compiling gwin_graph.c
Compiling gwin_button.c
Compiling gwin_slider.c
Compiling gwin_image.c
Compiling gwin_checkbox.c
Compiling gwin_label.c
Compiling gwin_radio.c
Compiling gwin_progressbar.c
Compiling gwin_list.c
Compiling gwin_container.c
Compiling gwin_frame.c
Compiling gwin_tabset.c
Compiling gwin_gl3d.c
Compiling gwin_keyboard.c
Compiling gwin_keyboard_layout.c
Compiling gwin_textedit.c
Compiling ginput.c
Compiling ginput_mouse.c
Compiling ginput_keyboard.c
Compiling ginput_keyboard_microcode.c
Compiling ginput_toggle.c
Compiling ginput_dial.c
Compiling gadc.c
Compiling gaudio.c
Compiling gmisc.c
Compiling gmisc_arrayops.c
Compiling gmisc_matrix2d.c
Compiling gmisc_trig.c
Compiling gmisc_hittest.c
Compiling gfile.c
Compiling gfile_fs_native.c
Compiling gfile_fs_ram.c
Compiling gfile_fs_rom.c
Compiling gfile_fs_fatfs.c
Compiling gfile_fs_petitfs.c
Compiling gfile_fs_mem.c
Compiling gfile_fs_chibios.c
Compiling gfile_fs_strings.c
Compiling gfile_printg.c
Compiling gfile_scang.c
Compiling gfile_stdio.c
Compiling gfile_fatfs_wrapper.c
Compiling gfile_fatfs_diskio_chibios.c
Compiling gfile_petitfs_wrapper.c
Compiling gfile_petitfs_diskio_chibios.c
Compiling gtrans.c
Compiling gdisp_lld_SSD1322.c
Compiling main.c
In file included from main.c:21:
oled.c:8:34: warning: 'rxbuf' defined but not used [-Wunused-variable]
    8 | CC_ALIGN_DATA(32) static uint8_t rxbuf[128];
      |                                  ^~~~~
Linking build/ch.elf
lto-wrapper.exe: warning: Options to Xassembler do not match: -alms=./build/lst/crt1.lst, -alms=./build/lst/hal.lst, dropping all -Xassembler and -Wa options.
Creating build/ch.hex
Creating build/ch.bin
Creating build/ch.dmp
Creating build/ch.list

   text	   data	    bss	    dec	    hex	filename
  38536	      0	  20480	  59016	   e688	build/ch.elf

Done

17:21:09 Build Finished. 0 errors, 3 warnings. (took 20s.472ms)

 

[Joel Bodenmann]

Regarding the warnings of GOS_NEED_X_THREADS and GOS_NEED_X_HEAP: It would seem like we're missing the default definitions of those. But I need to look into this more properly. I'm a bit thrown off by the fact that we haven't encountered this issue before and we're working on STM32 + ChibiOS projects every day.
For now, you can simply define them to GFXOFF in your gfxconf.h to be safe.

 

On 18/04/2022 at 16:57, AnSc said:

My debugger still does not work reliably, so I don't know at what point it crashes.

Are you able to debug your system properly now?

[AnSc]

Addition: this is the state of various variables when it fails.

g->priv is well within the memory range. So why does

ram = RAM(g)+xyaddr(x,y);

end up in such a high region?

[AnSc]

2 minutes ago, Joel Bodenmann said:

Are you able to debug your system properly now?

Currently it works, but no promises as how long.

[AnSc]

I thought about this a bit last night.

I don't understand how uGFX handles this "framebuffer" if this is what it is.

From my limited understanding of the code in gdisp_lld_SSD1322.c (lines 216, 217)  it looks to me like some "random" pointer somewhere into the RAM and not into some "reserved" area because of the "on-the-fly" calculation. There is no function call involved or I didn't get it.

How is there a safe-guard that this does not try to access non-RAM area or RAM area that other code uses?

		ram = RAM(g)+xyaddr(x,y);
		*ram &= ~xybits(x, y, LLDCOLOR_MASK());

Is there any working project (stub) that uses this display on this controller? So I could try to run this and compare to my code to exclude things on my end that may contribute to this error?

[AnSc]

Just found out that g->priv is a return from chHeapAlloc(). Therefore ChibiOS should raise an error in my opinion since the requested heap size results in an end address beyond RAM end.

Not sure what's happening there.

[AnSc]

I had an error in my calculation which Giovanni from ChibiOS pointed out:

Quote

64 * (256/2) is 8192 = 0x2000

0x20002fa8+0x2000 is 0x20004FA8 so within the heap limits.

It is the offset added to the base pointer that brings it out of the allocated block and into an unmapped area.

So the allocated memory is fine. But somehow the graphics driver goes beyond that. Where do I need to fix the code so that this does not happen any more?

[AnSc]

After playing with the numbers:

The end of the allocated block is at 0x20004FA8.

The calculation with the numbers from the affected code lines gives

(0x20002FA8+(255+63*128)) = 0x20005027

The difference is

0x20005027-0x20004FA8 = 127

This does not look like a random number. So where do those extra 127 come from?

It looks to me like x is too big.

ROW_WIDTH is SCREEN_WIDTH/2 and this value is used to allocate the memory:

Quote

g->priv = gfxAlloc(GDISP_SCREEN_HEIGHT * SSD1322_ROW_WIDTH);

Is'nt it then necessary to reflect this requirement also when trying to access the "framebuffer" for each pixel?

[AnSc]

As a quick test I just made a crude change to the code:

Quote

        ram = RAM(g)+xyaddr(x/2,y);
 

This does give me a nice picture of the uGFX logo for a short period after reset.

No crash.

Edited April 22, 2022 by AnSc

[AnSc]

After my initial euphoria I'm now stuck using the library as such.

Below is my code in my thread and it does not send any data to the display after initialization. I attached an oscilloscope to the chip select line and would expect to see data transfer to the display every 500 ms. But there is nothing. What am I missing?

Quote

THD_WORKING_AREA(waThreadOLED, 512);
THD_FUNCTION(ThreadOLED, arg) {

  (void)arg;
  chRegSetThreadName("OLED");

  spiStart(&SPID1, &hs_spicfg); /* SPI needs to be initialized before setting up the display */
  gfxInit();

  gdispSetPowerMode(powerOn);
  int width = gdispGetWidth();
  int height = gdispGetHeight();

  while (true) {

    chThdSleepMilliseconds(500);
    gdispDrawLine(5, 30, width - 50, height - 40, GFX_WHITE);
  }
}

 

[AnSc]

After quite some back and forth I got my debugger running again. Looks like it did not like to work on my USB hub… Used another USB and now it seems to work more reliably.

I found this thread here:

Then I added gdispFlush() to my code and voilla, line is displayed.
I find the documentation on that a bit lagging. This was not obvious from the examples I found.

However, maybe due to my crude hack, the line is a bit jagged:

 

[AnSc]

Fonts look like the high and low Half-Byte are swapped:

 

[AnSc]

Ok, I think I fixed it now:

Summary of all required changes:

Quote

diff --git a/drivers/gdisp/SSD1322/gdisp_lld_SSD1322.c b/drivers/gdisp/SSD1322/gdisp_lld_SSD1322.c
index eee32123..fd6d1224 100644
--- a/drivers/gdisp/SSD1322/gdisp_lld_SSD1322.c
+++ b/drivers/gdisp/SSD1322/gdisp_lld_SSD1322.c
@@ -51,7 +51,7 @@

 // Some common routines and macros
 #define xyaddr(x, y)           ((x) + (y)*SSD1322_ROW_WIDTH)
-#define xybits(x, y, c)                ((c)<<(((x)&1)<<2))
+#define xybits(x, y, c)                ((c)<<(((x+1)&1)<<2))

 /*===========================================================================*/
 /* Driver exported functions.                                                */
@@ -213,7 +213,7 @@ LLDSPEC gBool gdisp_lld_init(GDisplay *g) {
                        y = g->p.x;
                        break;
                }
-               ram = RAM(g)+xyaddr(x,y);
+               ram = RAM(g)+xyaddr(x/2,y);
                *ram &= ~xybits(x, y, LLDCOLOR_MASK());
                *ram |= xybits(x, y, gdispColor2Native(g->p.color));
                g->flags |= GDISP_FLG_NEEDFLUSH;

 

 

[Joel Bodenmann]

On 23/04/2022 at 16:26, AnSc said:

Then I added gdispFlush() to my code and voilla, line is displayed.

Flushing is indeed required by display drivers using the framebuffer approach: https://wiki.ugfx.io/index.php/Display_Driver_Model
If you don't like (or want to) flush manually, there is also built-in capabilities for flushing:

• GDISP_NEED_AUTOFLUSH To flush automatically
• GIDPS_NEED_TIMERFLUSH To flush periodically (based on a timer)

 

On 23/04/2022 at 16:26, AnSc said:

I find the documentation on that a bit lagging. This was not obvious from the examples I found.

Thank you for your feedback! I've added this to our ToDo list. We'll add/expand the documentation accordingly.

 

If I kept track of your messages correctly you're basically all set now, is that correct?
We certainly have to look into the SSD1322 driver at some point to determine whether this is a bug in the driver itself or simply a scenario depending situation in which case we'd need options/settings for that.

[AnSc]

5 hours ago, Joel Bodenmann said:

If I kept track of your messages correctly you're basically all set now, is that correct?

Yes this is right. Currently it works as expected on my side. Thanks for asking.

[Joel Bodenmann]

We've added the missing driver.mk file to the SSD1322 driver: https://git.ugfx.io/uGFX/ugfx/commit/143a3a884755577fd6e5bfbece01614512f840ca