GPIO Issues

Solved
dg012's picture
dg012
Junior(0)

I'm attempting to access GPIO pin 2 on the LTE IoT Starter Kit Gen 2 and I've been having some issues. Whenever I call the gpio command from the iot_monitor program I get a segmentation fault. I've also attempted to drive the pin via Linux's sysfs I/O system. This also does not seem to actually drive the pin. Any ideas on getting either of these to work?

When attempting to use sysfs I've navigated to sys/class/gpio, exported gpio2, and modified the direction and value files within gpio2. The pin still does not seem to be driven high.  

Thanks,

Daniel

jflynn129's picture
jflynn129
Moderator(4)

Hi Daniel, sorry I've not used sysfs to control the I/O and I'm not sure if it is fully implemented or not (this is part of the Linux port which I am not familiar with).  the gpio command in iot_monitor only will drive the RBG LED but there is an extended factory mode test that will exercise the GPIO 02 bin.  You can run the factory test by executing "iot_monitor -r5 -m -e" and it should perform a loopback test on GPIO 02. All the coded associated with that test is located in facttest.cpp contained in https://github.com/Avnet/M18QxIotMonitor

Hopefully with the info in that file and the test itself, you can get this working, if not please let me know.

 

dg012's picture
dg012
Junior(0)

Thanks for the reply. I ran the test specified in your response and got the following output for the IO tests:

---- XTEND IO Test 9 ------------------------------
XIO: cs_m1 ->rst_m1= FAIL
XIO: int_m1->pwm_m1= FAIL
XIO: cs_m2 ->rst_m2= FAIL
XIO: int_m2->pwm_m2= FAIL

I was not able to detect any voltage coming out of GPIO2 during the test. Any ideas?

 

 

 

dg012's picture
dg012
Junior(0)

 

Additionaly, I am unable to find the location where the functions gpio_init(), gpio_dir(), etc are located within the source code. These functions are used within the factory test. Do you know where these are located?

Thanks

PeterF's picture
PeterF
Moderator(16)

gpio_init(), gpio_dir(), etc are WNC Host-mode APIs (for hardware interface control functions). These are in the WNC hwlib, not in the application source code.

 

The gpio command in the io_monitor application is currently limited to support of just the three GPIOs that control the RGB LEDs (ie. GPIO_PIN_92, GPIO_PIN_101, GPIO_PIN_102), but can easily be edited and rebuilt to support other available GPIOs 

 

Please standby for an answer from WNC regarding sysfs manual control of GPIO_02 (using sys/class/gpio) 

dg012's picture
dg012
Junior(0)

Thank you.

I'm a little confused on the gpio commands in iot_monitor because in commands.cpp the comments seem to indicate that 92 corresponds to GPIO_PIN_2. Here is the portion of the source I am confused on: 

 

switch(indx) {
        case 92:  //GPIO_PIN_2
        case 101:  //GPIO_PIN_3
        case 102:  //GPIO_PIN_7
            do {
                done = (gpios[k].nbr == indx);
                k++;
                }
            while( k < _max_gpiopins && !done);
            k--; //k will always be 1 more than it should be, but done will be TRUE if found

            if (done) {
                printf("Setting GPIO_PIN_%d to %s\n",gpios[k].nbr,(state)?"1":"0");
                gpio_write( gpios[k].hndl, (state)?GPIO_LEVEL_HIGH:GPIO_LEVEL_LOW);
                break;
                }
        default:
            printf("ERROR: unknown binary i/o GPIO_PIN_%s\n",argv[1][9]);
            break;

        case 0:  
            printf("Invalid command syntax\n");
            break;
     }

 

The comments seem to indicate the GPIO_PIN_2 is already meant to be supported?

dg012's picture
dg012
Junior(0)

Thank you.

I'm a little confused on the gpio commands in iot_monitor because in commands.cpp the comments seem to indicate that 92 corresponds to GPIO_PIN_2. Here is the portion of the source I am confused on: 

 

switch(indx) {
        case 92:  //GPIO_PIN_2
        case 101:  //GPIO_PIN_3
        case 102:  //GPIO_PIN_7
            do {
                done = (gpios[k].nbr == indx);
                k++;
                }
            while( k < _max_gpiopins && !done);
            k--; //k will always be 1 more than it should be, but done will be TRUE if found

            if (done) {
                printf("Setting GPIO_PIN_%d to %s\n",gpios[k].nbr,(state)?"1":"0");
                gpio_write( gpios[k].hndl, (state)?GPIO_LEVEL_HIGH:GPIO_LEVEL_LOW);
                break;
                }
        default:
            printf("ERROR: unknown binary i/o GPIO_PIN_%s\n",argv[1][9]);
            break;

        case 0:  
            printf("Invalid command syntax\n");
            break;
     }

 

The comments seem to indicate the GPIO_PIN_2 is already meant to be supported?

jflynn129's picture
jflynn129
Moderator(4)

 

Can you email me directly at James.flynn@avnet.com

This forum so is considering my responses spam

jflynn129's picture
jflynn129
Moderator(4)

My applogies, the comments are incorrect. As Peter said earlier, the current implementation only supports the RGB LEDs (ie. GPIO_PIN_92, GPIO_PIN_101, GPIO_PIN_102).

alesalisa's picture
alesalisa
Junior(0)

Your blog has piqued a lot of real interest. I can see why since you have done such a good job of making it interesting. I appreciate your efforts very much. buffet catering service Doncaster

ArchieGallop's picture
ArchieGallop
Junior(0)

Various decent leaflet plans have been introduced on the page. On account of this site for offering essayroo services to us for our help. Continue sharing more. The handout is a blue tone and looks exceptional with further developed highlights.