GPIOs won't behave

Hi Alvin,

Welcome to E2E Forum.

Have you done pinmuxing properly for gpio pins which you are trying to access. By default most of the gpio pins are configured for different peripherals.

Please Refer GPIO User Guide ,

http://www.ti.com/lit/ug/sprue25a/sprue25a.pdf

I read about not using simulator but hardware, but not sure what it means.

It means in CCS you can run our test code without hardware also(using simulator).

Dear Arvind,

Thank you so much for your help!

Actually the PINMUX0 & 1 registers are described in the ARM document SPRUE14, not SPRUE25a. That's why I didn't notice the two registers.

Now I set the following on purpose, just to test which GPIOs I can actually use:

PINMUX0 (0x01c40000) &= 0x0000001F; // 0 = default = GPIO, leaving the final 5 bits "AEAW" alone for EMIFA

PINMUX1 (0x01c40004) = 0x00000000;

BOOTCFG (0x01c40014) &= 0x0000001F; // Again leaving the last 5 bits for EMIFA

I believe the EMIFA is the bus for DDR (which I need to use of course), so the corresponding GPIOs (10:28, 52:53) are out of the count.

When I run the program, I found that there are still several GPIOs that are stuck, namely: GPIO 0:3, 5, 7, 35, 46; GPIO3V 1:2, 7:14. That means I can only control 30 pins.

I do not use LCD or CCD. I do not use ethernet (that's EMAC right, correct me if I am wrong). Are there any other registers that mask me from controlling these stuck GPIOs?

Thank you very much. Any help will be appreciated.

Regards,

AL

Hi AL,

Can you please attach your project so that i can reproduce the issue at my end also.

Dear Arvind,

Sure, but how can I attach files? I don't see any options to attach files.
Should I include the libraries too? I use the "davincievmbsl.lib" with the CSLs. Not sure if everybody uses the same libraries.
I can give the screenshots too.

Regards,
AL

Use "Use rich formatting" and you would get "attach" option to attach the files.

Dear all,

Thanks for the tip. I attach the project here in zip. It contains the library (lib) and my project for GPIOs (named ddr, because I edit the code directly from the ddr-testing demo codes). Please kindly inform me if you need anything else.

Regards,

ALddr.zip

Hi Alvin,
Could you please tell me what is your requirement here.
What are you trying to do with all GPIOs ?

Dear Titus,

My project is to get data from 3 separate sets of cameras (front-end processed through their respective FPGAs), each with 11 pins (8-bit data in parallel + frame valid + line valid + clk), store them into DDR using the ARM, then do image processing using the DSP, and finally send the processed image to the outside (the control board of another party). The MCU also needs to receive commands through RS485 and give commands to the cameras through SPI.

Sending camera data in serial is not possible because the camera data is 1280x1024 ( = 1MB ), the GPIO max frequency is 10MHz, and my output data has to be 2 frames per second, so I will not have time to do all the processing if I receive data in serial. This is why I (or our team) need to have so many GPIOs. Another method is to consider multiplexing the inputs, but it will cost another FPGA and PCB space is very limited here. One reason we chose 6446 is because of the high number of GPIOs.

Hope I answered your question.

Regards,
AL

When I run the program, I found that there are still several GPIOs that are stuck, namely: GPIO 0:3, 5, 7, 35, 46; GPIO3V 1:2, 7:14. That means I can only control 30 pins.

I do not use LCD or CCD. I do not use ethernet (that's EMAC right, correct me if I am wrong). Are there any other registers that mask me from controlling these stuck GPIOs?

Able to access GPIO0,GPIO1,GPIO2, and GPIO3 ?
Have you checked the pin functionality after you done multiplexing for GPIO in CCS via emulator ?
ie GPIO0 to GPIO3 got selected after pinmuxing ?
Try to disable all the GPIOs and just try these 3 GPIOs which you seen not functioning (several GPIOs that are stuck)

Dear Titus,

I am able to configure the GPIO directions, but cannot modify some of the data.

PINMUX0 = 0x00000000; // enable all GPIOs
GPIO_DIR01 = 0x00000000; // set direction to output
GPIO_OUT_DATA01 = 0x00000000; // set the GPIOs to 0
printf("%x\n", GPIO_IN_DATA01); // Print out the GPIO => I get 0x0000002F, i.e. GPIO pins 0-3, 5 are stuck at high

GPIO_OUT_DATA01 = 0xFFFFFFFF; // set the GPIOs to 1
printf("%x\n", GPIO_IN_DATA01); // Print out the GPIO => I get 0xFFFFFF7F, i.e. GPIO pin 7 is stuck at low

Now, PINMUX0 = 0xFA7FFFFF; // disable all GPIOs except GPIO 0-3

Try the same test,
GPIO_OUT_DATA01 = 0x00000000; // set the GPIOs to 0
printf("%x\n", GPIO_IN_DATA01); // Print out the GPIO => I get 0x00000027, i.e. GPIO pins 0-2, 5 are stuck at high

GPIO_OUT_DATA01 = 0xFFFFFFFF; // set the GPIOs to 1
printf("%x\n", GPIO_IN_DATA01); // Print out the GPIO => I get 0xE0000067, i.e. GPIO pin 3 is stuck at low now

I checked the GPIO_DIR registers and confirms that the directions are correct.

Is my checking method wrong? Or is there something that masks my precious GPIOs? Thanks for all your help, and any more help will be highly appreciated.

Regards,

AL

Sorry for the too many questions :-)

I checked the GPIO_DIR registers and confirms that the directions are correct.

How did you check the "GPIO" registers DIRECTION,OUT,IN,PINMUX etc., ?

How did you connect that particular GPIOs in hw (2-5) those got hang ?

Did you probe via oscilloscope those pins while you access ?

Dear Titus,

No problems, as I admit I am a newbie and I need to learn a lot through discussions. I will be reading and posting in this forum many times.

For checking the registers, I make software breakpoints and read from the memory. I also print the register values onto the console to check.

Since I am in the early stage of the development, I made no extra connections to the GPIOs. According to the datasheets, when the GPIOs are set to output mode, the GPIO_IN_DATAx reflects the GPIO values that are written in. So I first check the GPIO_IN_DATAx registers to see if they behave. I figure that if the registers do not behave, then the hardware won't behave either, so I did not use probes to measure the voltages. Once the registers are correct, I will use the probes.

Is this the correct way? Or should I not trust the registers and test the hardware instead?

Regards,
AL