Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

segmentation fault

Status
Not open for further replies.

electroRF

Member
Hi,
I'm running the following application on AM335X (ARM), and getting Segmentation Fault at run-time on the line :
C:
    value = *(reg); // Segmentation Fault here!

Here is the simple program itself:

C:
#include <stdio.h>
#include <unistd.h>
#include <string.h>

#define GPIO1_BASE      0x4804C000 // Start Address
#define GPIO_OE         0x0134 // Offset
#define GPIO_DATAOUT    0x013C // Offset
#define GPIO1_16        16

int main(int argc, char** argv)
{
    volatile unsigned int* reg;
    unsigned int value;

    /* LED Setup and Turn-on */
    reg = (volatile unsigned int*)(GPIO1_BASE + GPIO_OE);
    value = *(reg); // Segmentation Fault here!
    value &= ~(1 << GPIO1_16);
    *(reg) = value;
    reg = (volatile unsigned int*)(GPIO5_BASE + GPIO_DATAOUT);
    value = *(reg);
    value |= (1 << GPIO1_16);
    *(reg) = value;

    return 0;
}

Do you have an idea why I get this Segmentation Fault?

Thank you very much.
 
In Linux you normally need to mmap the physical device address to a virtual memory address as the physical pages are accessed by the system MMU. That BASE address in userland might be a illegal or non-existing memory access. For a user program the process memory map device can be used to map addresses.
https://elinux.org/EBC_Exercise_11b_gpio_via_mmap
 
Hi NSA,
Thanks a lot!

I read the great link! :)

Oh regarding what you said, I think it's the opposite, i.e. the BASE Address of the GPIO (which can be read in datasheet) is the physical address, while the Address returned from mmap is the virtual address.

I have two question please.

1. When I access the Virtual File System (VFS) of GPIO1_15, I did not disable the interface clock, and the GPIO1_15 indeed turned off and on the leg as I instructed.

Was it a "coincidence", i.e. the GPIO wa already configured to OUT, or does the VFS take care of that for you?

2. I think that when writing directly to GPIO, you need to first disable the Interface clock ---> Then change the settings ---> then enable the Interface Clock, right?
 
Hi NSA,
Thanks a lot!

I read the great link! :)

Oh regarding what you said, I think it's the opposite, i.e. the BASE Address of the GPIO (which can be read in datasheet) is the physical address, while the Address returned from mmap is the virtual address.

I have two question please.

1. When I access the Virtual File System (VFS) of GPIO1_15, I did not disable the interface clock, and the GPIO1_15 indeed turned off and on the leg as I instructed.

Was it a "coincidence", i.e. the GPIO wa already configured to OUT, or does the VFS take care of that for you?

2. I think that when writing directly to GPIO, you need to first disable the Interface clock ---> Then change the settings ---> then enable the Interface Clock, right?

I think we agree about the address translation. The BASE physical address is where the MMU does physical R/W operations to as it translates your programs virtual address I/O back and forth to physical memory addresses. I've not looked at the BeagleBones VFS driver code but usually generic I/O config details are usually handled in a transparent manner to the user if you export a pin from the GPIO.
https://groups.google.com/forum/#!topic/beagleboard/OYFp4EXawiI
**broken link removed**

My recent programming experience with ARM devices involved kernel level GPIO drivers (for a personal project so it's not in the Linux kernel) on the RPi for use with the 'Comedi' Linux DAQ C interface library but that was with kernel 3.2 interfaces so I'm not up to speed on the BeagleBone Black hardware requirements as the mainline Linux ARM SoC support is still in flux.
 
Last edited:
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top