This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Setting GPIO H3 as output causes memory overwright

Hello all,

I'm using LM4F232H5QD on a custom board.

compiler: IAR, Embedded Workbench 6.4

The system runs with clock of 80Mhz

During HW init procedure, GPIO H3 is configured as output as following:

ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOH);
ROM_GPIOPinTypeGPIOOutput(GPIO_PORTH_BASE, GPIO_PIN_3);
ROM_GPIODirModeSet(SYSCTL_PERIPH_GPIOH, GPIO_PIN_3, GPIO_DIR_MODE_OUT);

When ROM_GPIODirModeSet is executed, memory ovewrite occurs on address: 0x200004A0.

This address holds data of a global variable.

I get this behaviour when using both debuggers I-Jet and J-Link, and also when running free without debugger and loading the FW using the boot loader through UART0 using LM Flash Programmer.

The variable, which is being overwritten is a cell in array of pointers.

The array is defined as follow:

static char *ptSystemBIT[]=
{
"\r\nSystem Diagnostics\r\n",
"------------------\r\n",
"1. General BIT\r\n",
"2. R&D Internal\r\n",
"3. Keyboard\r\n",
"4. Mouse\r\n",
"5. Face\r\n",
"6. Back to main menu\r\n\r\n"
};

Map file allocation is as follow:

ptSystemBIT             0x20000490   0x20  Data  Lc  UserInterface.o [1]

I don't understand how GPIO setting can cause this problem. I tried other GPIO and it was ok (or it could be I get memory overwrite in a place I didn't find).

I'll appreciate any help.

Thank you all in advance,

Yanki

  • Hi,

    I think you are passing a wrong parameter (the first one) when calling GPIODirModeSet() - this should be GPIO_PORTH_BASE instead SYSCTL_xxxx - the library code shows for this parameter : ui32Port.

    Petrei

  • Hi Petrei,

    Thank you for your fast response.

    Accordinh to ROM user guide document, the parameter should be SYSCTL_PERIPH_..., but I also noticed the note there:

    It takes five clock cycles after the write to enable a peripheral before the the peripheral is
    actually enabled. During this time, attempts to access the peripheral will result in a bus fault.
    Care should be taken to ensure that the peripheral is not accessed during this brief time period.

    I entered a delay using ROM_SysCtlDelay and it seems to be o.k now.

    I hope this solves my problem.

    Yanki

  • Hello again,

    Petrei, I apologize. You are right. I mixed up with ROM_SysCtrlPeripheralEnable.

    I wish you all the best.

    Yanki