GPMC Clock and CS

Midson:

Can you show us what you changed in kernel to enable your new memory area with CS4?

Did you check that gpmc_ncs4 is selected by pin muxing?

Regards,

Michael T

Midson:

In u-boot, in "./board/ti/evm/evm.h" the GPMC_NCS4 pin is configured as the GPMC_NCS4 function with an

internal pull-up.

 MUX_VAL(CP(GPMC_NCS4),  (IEN  | PTU | EN  | M0)) /*GPMC_nCS4*/\

I don't see anything in Linux kernel that changes this.

Regards,

Michael T

I would suggest to use devmem application and directly read pad configuration to verify if any other driver/module is reconfiguring to something else.

Thanks,

Vaibhav

Hello Midson,

You need to make sure you are setup for synchronous mode.  Please refer to section 10.1.5.3.6 of the Technical Reference Manual (link below).

http://focus.ti.com/general/docs/lit/getliterature.tsp?literatureNumber=sprugn4i&fileType=pdf

Thanks Jeff. Already we  gone thru the session and set the CS7 Bit 24 in the code. 

1. Our Register values are:

GPMC_CONFIG1 = 0x7B42_1201; 
GPMC_CONFIG2 = 0x0010_1400; 
GPMC_CONFIG3 = 0x0002_0200; 
GPMC_CONFIG4 = 0x1000_1404; 
GPMC_CONFIG5 = 0x0203_0C0D; 
GPMC_CONFIG6 = 0x0000_02C2;


2. We have Updates the Padconf register in Uboot with new value

/* Enable GPMC_CLK Pin in CONTROL_PADCONF_gpmc_ncs7 register */
(*(volatile int *)(OMAP34XX_CTRL_BASE + 0xBC)) |= 0x01180000;

3. devmem output:

# ./devmem 0x480020BC w
/dev/mem opened.
Memory mapped at address 0x40009000.
Value at address 0x480020BC (0x400090bc): 0x180118

Still we are unable to see the GPMC Clock out?

Hi

I have similar issue. I'm working with GPMC on OMAP3530 / AM3517 to access FPGA.

1. I am not able to see GPMC_CLK signal on Logic Analyzer . I configured Chip select in SYNC NOR 16 bit Multiple Write/Read Mode. I am testing only Write operation. Do I need to set anything in PADCONF GPMC register for clock ? If yes please let me know as what need to do ?

2. Can u suggest as how to use DMA for write operation, I saw OMAP nand code, and did the same, but I couldnt see any data transferring, but data transfer is happening through raw_write operation ? Any suggestions please...

Thanks

Vijay

Hello Midson,

For the GPMC_CLK, you need to also make sure you are setting the Pad config for gpmc_clk to be mode 0.  by default after reset it will be in safe mode (mode 7). 

for the question on using async and sync devices, you are ok as long as you set them up properly per each CS. 

I am very sorry. Settings are correct. But the issue is, due to the wrong threshold 
level (TTL) setting the LA. In LVCMOS, I am able to see the clock. Now trying check 
the other parameters.

Anyway, Jeff can you please explain, what do you mean by "setting the Pad config
for gpmc_clk to be mode 0"?

Now, if I do one write in the driver, I am seeing 2 write operations with consecutive 
addresses in LA. Both write is happening on separate CS signal?

Hi,

Last week while surfing through TRM I just came across below section (11.1.3.2.1 Clocking), not sure whether this is applicable for you -

--------------------------Pasted from TRM-------------------

NOTE: When the GPMC is configured for synchronous mode, the GPMC_CLK signal (which is an
output) must also be set as an input (CONTROL.CONTROL_PADCONF_GPMC_NCS7[24]
INPUTENABLE1 = 1). GPMC_CLK is looped back through the output and input buffers of
the corresponding GPMC_CLK pad at the device boundary. The looped-back clock is used
to synchronize the sampling of the memory signals.

-----------------------------End-----------------------------------

Thanks,

Vaibhav

I just looked at your devmem output you pasted in this thread -

# ./devmem 0x480020BC w
/dev/mem opened.
Memory mapped at address 0x40009000.
Value at address 0x480020BC (0x400090bc): 0x180118

The GPMC_CLK is not configured as a input, please refer to the pad configuration section in TRM.

Thanks,
Vaibhav

Hello Midson,

I was talking about the mux mode (bits 2:0) of the padconf register, but after looking over the value you are writing to that register you are putting it into mode 0 so it should be working fine as you stated. 

for the CS question.  Are you using both of the CS that are having the writes occur?  If not, you need to make sure that the CS you are not wanting to use is not setup. 

I'm having (I think) the same exact problem - trying to talk to an external FPGA card with a synchronous GPMC interface on an AM/DM37x EVM but the FPGA is not seeing any GPMC_CLK signal.  What exactly do I have to do to enable the clock?  I am working in u-boot source at the moment.

I'm having trouble following the sense of this thread. I'll probably figure this out before anyone answers, but just in case I don't could someone post the answer before I do? :-)

Only during the data transfer, you can see the clock. Can you share some info on what you have done so for?

Apparently our problem was something about the GPMC_CLK pin not being connected to the right pin on the FPGA board.  (makes it really hard for the FPGA to see the clock!).

You can test this, even with-out connecting the FPGA. Just transmit the data and connect the LA or Hi-end Scope to the Clock pin to see whether the signal is coming out or not.

Obviously we didn't have a logic analyzer ("LA") or scope attached to the clock pin.

Hi,

Sorry for upping this old post, but I have the same problem and I don't understand the following :

Why do you set the GMPC_NCS7 as an input in padconf when you say the GPMC_CLK should be (using synchronous mode)?

Thanks,

CMR

Okay I found my answer, padconfs are 16 bit configurations on 32bit register, so CLK is on NCS7 msb side. Sorry for this!