Memory allocation out of range?

[AnSc]

Hi,

now that my initial problems with SPI are solved I now cannot get my OLED running.
I wanted to use uGFX as the graphics library and I _think_ I did set it up correctly. Nothing fancy just some adjustments to ChibiOS.

I get it to compile and I can step into the execution with the debugger.

However, I get an error "unhandled exception" and it looks to me that this is caused by ChibiOS trying to access a memory address that is out of range.

The debugger tells me:

Code: Select all

ram   gU8 *   0x20005027 <error: Cannot access memory at address 0x20005027>   


I use a STM32F103RBT6 with 20 kB RAM. From my calculations (hoping they are correct) this would translate to 0x5000 RAM amount. Which would make the last memory address 0x2000 4fff in my understanding.

If this is correct, why would ChibiOS try to access 0x2000 5027? Also, the allocation of this memory does not throw an error but the first access to it does.

I defined the MCU in my board.h this way:

Code: Select all

/*
 * MCU type, supported types are defined in ./os/hal/platforms/hal_lld.h.
 */
#define STM32F103xB

in the Makefile there is

Code: Select all

# Target settings.
MCU  = cortex-m3
…
include $(CHIBIOS)/os/common/startup/ARMCMx/compilers/GCC/mk/startup_stm32f1xx.mk
# HAL-OSAL files (optional).
include $(CHIBIOS)/os/hal/hal.mk
include $(CHIBIOS)/os/hal/ports/STM32/STM32F1xx/platform.mk

…
# Define linker script file here
LDSCRIPT= $(STARTUPLD)/STM32F103xB.ld


I'm not sure about this line, this comes from the project I copied from:

Code: Select all

include $(CHIBIOS)/os/common/ports/ARMv7-M/compilers/GCC/mk/port.mk

Any ideas what could be wrong? Any setting I'm missing?

[Giovanni]

Hi,

Which code is accessing that location? "ChibiOS" is pretty generic, it could not even be ChibiOS code doing that directly. Try to determine which line is doing the access.

Giovanni

[AnSc]

Hi,

thanks for the reply.

I have also opened a thread on the uGFX forum, because I'm just starting and do not have any fancy code running and I'm out of ideas why this does not work.

https://community.ugfx.io/topic/4340-ug ... k-missing/

This happens during the initialization of uGFX.
the line of code that triggers this error is:

Code: Select all

*ram &= ~xybits(x, y, LLDCOLOR_MASK());

This is line 217 in the file gdisp_lld_SSD1322.c from uGFX (./ugfx/drivers/gdisp/SSD1322/).

The guys from uGFX say they use ChibiOS functions to access the memory. Quote:

All memory management related functions are mapped to the underlying ChibiOS system.

This is the reason I opened this question here.

[Giovanni]

There is no ChibiOS code in that line, the variable "ram" is pointing to a wrong location. Verify in the .map file that memory allocation is what you expect, that is linker work.

Giovanni

[AnSc]

Thanks again and sorry to bother again.

I'm not sure what information the map file provides. I could not find any address that looks like the problem reported by the debugger.
Maybe you could spare a minute or two to look if there is something suspicious?
Here's a link to the ch.map file: https://1drv.ms/u/s!Anw9hmjJeZtlllsEoj1 ... d?e=uwcqho

Is this the right file? Or is there another location where I need to look?

[Giovanni]

Where is declared and initialized that "ram" variable?

[AnSc]

This is what I could find:

Code: Select all

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

RAM, LLDCOLOR_MASK translate to:

Code: Select all

#define RAM(g)                       ((gU8 *)g->priv)
#define LLDCOLOR_MASK()               ((1 << LLDCOLOR_BITS)-1)
#define LLDCOLOR_BITS                (GDISP_LLD_PIXELFORMAT & 0xFF)
#define GDISP_LLD_PIXELFORMAT         GDISP_PIXELFORMAT_GRAY16
#define GDISP_PIXELFORMAT_GRAY16      (GDISP_COLORSYSTEM_GRAYSCALE|0x0004)
#define GDISP_COLORSYSTEM_GRAYSCALE       0x4000


xyaddr() and xybits are defined:

Code: Select all

#define xyaddr(x, y)      ((x) + (y)*SSD1322_ROW_WIDTH)
#define xybits(x, y, c)      ((c)<<(((x)&1)<<2))
#define SSD1322_ROW_WIDTH         (GDISP_SCREEN_WIDTH/2)
#define GDISP_SCREEN_WIDTH      256

and g->priv points according to the debugger to:

Code: Select all

priv   void *   0x20002fa8   

[Giovanni]

I think the value of "ram" is that wrong address, inspect it just before the crashing line.

Giovanni

[AnSc]

I just thought about it a bit more. I hope I can get to the bottom of this.

This is what I found today after reading further into the code:
gdisp_lld_SSD1322.c

Code: Select all

#ifndef GDISP_SCREEN_HEIGHT
   #define GDISP_SCREEN_HEIGHT      64
#ifndef GDISP_SCREEN_WIDTH
   #define GDISP_SCREEN_WIDTH      256
#define SSD1322_ROW_WIDTH         (GDISP_SCREEN_WIDTH/2)


line 69

Code: Select all

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

results in

Code: Select all

chHeapAlloc(0, 64 * (256/2));

which is 8480 or 0x2120 bytes.

from the offset seen in the debugger output (returned pointer to 0x20002fa8) this results in an end address of 0x200050C8 in my calculation.
RAM end is at 0x20005000.
Why does this not give an error during heap allocation?
The code checks for:

Code: Select all

   if (!g->priv)
      return gFalse;

But when stepping through this there is no error.
What am I missing here?

[Giovanni]

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.

Giovanni