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.

Problem using the GPMC bus to access an external FPGA device

Other Parts Discussed in Thread: SYSCONFIG

Hi,

   In our design, we planned to use the GPMC bus to exchange datas between the DM8148 and our FPGA.  We configured the GPMC in NOR mode for synchronous single read and write accesses and with the datas multiplexed with the lower 16 bits of addresses. 

  Unfortunately, writing to the base address we set (0x1000000), we are'nt able to have the data present on the bus.  According to what we grabbed with a scope (see attach picture) every control signal behaves as expected but the "lower 16 bits" are not displaying the datas we would like to write during the WE active period...

Here's the GPMC register values we set :

writel(0x00000008, &gpmc_cfg->sysconfig);        
writel(0x00000000, &gpmc_cfg->irqstatus);        
writel(0x00000000, &gpmc_cfg->irqenable);        
writel(0x000001F1, &gpmc_cfg->timeout_control);  
writel(0x00000012, &gpmc_cfg->config);           

GPMC_CONFIG1_i  0x28401200
GPMC_CONFIG2_i  0x40500  
GPMC_CONFIG3_i  0x20201  
GPMC_CONFIG4_i  0x4030503
GPMC_CONFIG5_i  0x40405  
GPMC_CONFIG6_i  0x40001C0
GPMC_CONFIG7_i  0xF41    

for i = 0 as we use only CS[0] for now...  Other CS are disabled...

And here is a picture of what we observe on the bus when writing datas "0xFFFFFFFF" at address "0x1000000"

 

D13 = CS[0]               
D12 = ADV_ALE_n           
D11 = GPMC_WE             
D[7..0] = GPMC_AD[7..0]   

As this is two 16 bits access, adresses seems to be ok (0x0 and 0x1) under the ADV_ALE signals but we would have expect bits 7 to 0 to change for 0xFF during the active period of the WE signal (D11 active low) as the data we would like to write is all "F"...

Is someone have a hint for us...?  It probably has something to do with the GPMC register config but as far as we know, the whole thing seems ok for us...?!

Regards!

Seb

  • I forgot to mention that the upper bits of the address part [27..17] are always stuck to 0x3FF...  As I write to 0x1000000, I would have expect them to be '0' at least for bits [23..17]...

     

    Seb

  • Ok guys I just found my problem.  Bits 19-16 (WRDATAONADMUXBUS) of GPMC_CONFIG6_i register was not set correctly.

    Sorry if you spent some time on this.

    Regards!

    Seb

  • Here is what I suggest to try:

    1. Reset the WAITREADMONITORING.  Which is changing bit 22 of GPMC_CONFIG1 to 0.
    2. Is your address and data multiplexed?  If not, please change bit 9-8 of GPMC_CONFIG1 to 0.

    Regards,

    Viet

  • Hi Sebastien,

    Is your problem of [23..17] getting stuck to '1' got resolved?? If so, can you please explain how?? 

    Regards

    Vaishnavi

  • Regarding the lines [26..17] stucked issue, it have been cause by a mistake in the technical reference manual I got at this time.  For a multiplex bus, it was mention in table 10-2 to connect GPMC_A[26..16] for the upper adress bits.  However, the pins that drives the upper nibbles of the bus (address 27 to 17) are in fact GPMC_A[11..1] in this mode.  It cost me a board revision but it now work as expected.

  • Hi Sebastien,

    Even I am using the same address/data multiplexed mode. We have connected GPMC_A[11..1] that drives the upper nibbles as in TRM. But I'm unable to drive GPMC_A[11] line.

    Also, you are writing "writel(0x00000012, &gpmc_cfg->config);"  which means that LIMITED_ADDRESS_BIT is set.  Do gpmc worked without changing this??

    Can you please give me all the gpmc register values what you have written and also in the same order?? That would be more helpful.  

    Regards

    Vaishnavi

  • Hi,

      I cannot certify that the GPMC_A[11] pins is toggling as we don't need that much space in our application.  It's been a while since we work on this and I cannot validate it right now.

      I cannot answer your question about the LIMITED_ADDRESS bit neither as we always used it set.  As I told, we don't need the full address range in our application.

      Here's my GPMC reg. configuration if it helps :

     

    Address = 0x50000010   Value = 0x8

    Address = 0x50000014   Value = 0x1

    Address = 0x50000018   Value = 0x0

    Address = 0x5000001C   Value = 0x0

    Address = 0x50000020   Value = 0x0

    Address = 0x50000024   Value = 0x0

    Address = 0x50000028   Value = 0x0

    Address = 0x5000002C   Value = 0x0

    Address = 0x50000030   Value = 0x0

    Address = 0x50000034   Value = 0x0

    Address = 0x50000038   Value = 0x0

    Address = 0x5000003C   Value = 0x0

    Address = 0x50000040   Value = 0x0

    Address = 0x50000044   Value = 0x0

    Address = 0x50000048   Value = 0x0

    Address = 0x5000004C   Value = 0x0

    Address = 0x50000050 Value = 0x10

    Address = 0x50000054 Value = 0x301

    Address = 0x50000060   Value = 0x28601200

    Address = 0x50000064   Value = 0x30400

    Address = 0x50000068   Value = 0x10100

    Address = 0x5000006C   Value = 0x3010402

    Address = 0x50000070   Value = 0x30304

    Address = 0x50000074   Value = 0x20102C0

    Address = 0x50000078   Value = 0xF41

    Address = 0x50000090   Value = 0x28601200

    Address = 0x50000094   Value = 0x30400

    Address = 0x50000098   Value = 0x10100

    Address = 0x5000009C   Value = 0x3010402

    Address = 0x500000A0   Value = 0x30304

    Address = 0x500000A4   Value = 0x20102C0

    Address = 0x500000A8   Value = 0xF42

    Address = 0x500000C0   Value = 0x1000

    Address = 0x500000C4   Value = 0x101001

    Address = 0x500000C8   Value = 0x22060514

    Address = 0x500000CC   Value = 0x10057016

    Address = 0x500000D0   Value = 0x10F1111

    Address = 0x500000D4   Value = 0x8F070000

    Address = 0x500000D8   Value = 0x0

    Address = 0x500000F0   Value = 0x1000

    Address = 0x500000F4   Value = 0x101001

    Address = 0x500000F8   Value = 0x22060514

    Address = 0x500000FC   Value = 0x10057016

    Address = 0x50000100   Value = 0x10F1111

    Address = 0x50000104   Value = 0x8F070000

    Address = 0x50000108   Value = 0x0

    Address = 0x50000120   Value = 0x28601200

    Address = 0x50000124   Value = 0x30400

    Address = 0x50000128   Value = 0x10100

    Address = 0x5000012C   Value = 0x3010402

    Address = 0x50000130   Value = 0x30304

    Address = 0x50000134   Value = 0x20102C0

    Address = 0x50000138   Value = 0xF43

    Address = 0x50000150   Value = 0x1000

    Address = 0x50000154   Value = 0x101001

    Address = 0x50000158   Value = 0x22060514

    Address = 0x5000015C   Value = 0x10057016

    Address = 0x50000160   Value = 0x10F1111

    Address = 0x50000164   Value = 0x8F070000

    Address = 0x50000168   Value = 0xF00

    Address = 0x50000180   Value = 0x1000

    Address = 0x50000184   Value = 0x101001

    Address = 0x50000188   Value = 0x22060514

    Address = 0x5000018C   Value = 0x10057016

    Address = 0x50000190   Value = 0x10F1111

    Address = 0x50000194   Value = 0x8F070000

    Address = 0x50000198   Value = 0xF00

    Address = 0x500001B0   Value = 0x1000

    Address = 0x500001B4   Value = 0x101001

    Address = 0x500001B8   Value = 0x22060514

    Address = 0x500001BC   Value = 0x10057016

    Address = 0x500001C0   Value = 0x10F1111

    Address = 0x500001C4   Value = 0x8F070000

    Address = 0x500001C8   Value = 0xF00

     

    Regards!

     

     

  • Hi Sebastien,

    Thank you so much for your reply. 

    Anyways I got a reply today from TI that there is some bug in TRM. I think this issue may get solved If I try that solution given by TI.  Reference for that link is,

    http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/p/235797/847650.aspx#847650

    Regards

    Vaishnavi

  • Hello Sebastien,

    We are also planning to use the GPMC bus to exchange data between DM8148 and fpga. We configured the GPMC in NOR mode for synchronous single read and write accesses and with the datas multiplexed with the lower 16 bits of addresses. 

    I am using ti-ezsdk_dm814x_05_05_02_00 for my developments.

    My question is, how to make sure the changes i am doing in u-boot for gpmc configuration and mux settings are not over-written in kernel, as i know in the dm8148_evm is using the same interface for nand flash. 

    Can you please guide me, what parts i need to disable in Kernel, in case i didn't intend to use GPMC interface for NAND or NOR flash?

    br

    Vikas