• State Resolved
  • Locked Locked
  • Replies 14 replies
  • Answers 3 answers
  • Subscribers 98 subscribers
  • Views 2257 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CCS/AM3352: GPMC settings

user1201164
Expert 1770 points

Part Number: AM3352

Tool/software: Code Composer Studio

Hi,

Our customers are attempting memory access of FPGAs using GPMC.
There is no problem with 1024 times Reading.
However, when Write is executed, it will be intermittently executed and will stop halfway.
(See attached file CH1: GPMC_CLK, CH2: CS, CH3: ADV, CH4: WE)
The setting is "Non Multiplexed, 16 bit, NOR, Synchronous".
The clock is 100 MHz.
The WAIT signal from the FPGA remains high.

The setting to the GMPC register is as follows.
-GPMC_CONFIG : 0x00000000
-GPMC_CONFIG1_0 : 0x28001000
-GPMC_CONFIG2_0 : 0x000B0B01
-GPMC_CONFIG3_0 : 0x00040401
-GPMC_CONFIG4_0 : 0x09060905
-GPMC_CONFIG5_0 : 0x00090D0D
-GPMC_CONFIG6_0 : 0x090306C3
-GPMC_CONFIG7_0 : 0x00000F50

The source of the write test is as follows.

void PioWrite (void)
{
    unsigned long i = 0;
    for (i = 0; i <1024; i ++)
    {
        * (volatile unsigned long *) 0x10000000 = 0;
    }
}

If there is something to check, please let me know if you notice anything.

Best Regards,

Kouji Nishigata

  • 0
    TI__Guru**** 393215 points
    Hi,

    Try to relax the GPMC settings and see if the issue occurs again.
  • 0 in reply to Biser Gatchev-XID
    Expert 1770 points

    HI,

    They are experimenting with changing some patterns, but the situation does not seem to change.
    The next data is the timing that I made with reference to Figure 7-21 of TRM.
    -GPMC_CONFIG 0x00000000
    -GPMC_CONFIG1_0 0x28001000
    -GPMC_CONFIG2_0 0x00120B01
    -GPMC_CONFIG3_0 0x00060401
    -GPMC_CONFIG4_0 0x10070905
    -GPMC_CONFIG5_0 0x0009130D
    -GPMC_CONFIG6_0 0x090706C3
    -GPMC_CONFIG7_0 0x00000F00


    Also, they are trying changing the following parameters.
    -CSWROFFTIME: 11 to 18
    -ADVWROFFTIME: 4 to 6
    -WEOFFTIME: 9 to 16
    -WEONTIME: 5 to 8
    -WRCYCLETIME: 13 to 19
    -WRDATAONADMUXBUS: 3 to 7

    If there is something to check, please let me know if you notice anything.

    Best Regards,

    Kouji Nishigata

  • 0 in reply to user1201164
    Expert 1770 points
    HI,

    I thought it was the timing of GPMC as a reason for not being able to write continuously.
    But are there any other possible causes?
    Is there anything else I should investigate?

    Best Regards,
    Kouji Nishigata
  • 0 in reply to user1201164
    Expert 1770 points
    Hi,

    Although this problem taked time, but it is not solved.

    Customer put a wait time at the time of writing.
    It means that this time was output at about 800nsec.

    void PioWrite(void)
    {
    unsigned long i = 0;
    for (i = 0; i < 1024; i++)
    {
    *(volatile unsigned long *)0x10000000 = 0;
    wait_process(); // wait about 800nsec
    }
    }

    However, this is too slowly and not practical.
    What is interfering with the output?

    Best Regards,
    Kouji Nishigata
  • 0 in reply to user1201164
    TI__Guru* 94781 points

    Kouji,

    is this single threaded code?  What codebase is performing the AM335x initialization?  I don't think this issue is related to GPMC write timing.  It seems something else is pre-empting the GPMC writes.

    Regards,

    James

  • 0 in reply to JJD
    Expert 1770 points
    Hi, James
    Thanks for the response.

    I ask a customer for confirmation, but I does't understand the meaning of your comment.

    For the first single threading and initialization, are you checking the setting of GPMC and the order of writing data?
    Since the timing of GPMC has changed with the changed value, I think whether data is being written after setting.

    Also,
    > It seems something else is pre-empting the GPMC writes.
    For example, what kind of example can be considered concretely?
    I can't think of how to do "pre-empting the GPMC writes" right away.

    Best Regards,
    Kouji Nishigata
  • 0 in reply to user1201164
    Expert 1770 points
    HI,

    This problem is solved by setting the memory type to "strong order" in MMU.
    However, I thought that writing times are not omitted even in the case of device memory.
    Was this recognition wrong?
    Or is it a special case of writing the same data to the same address?

    Best Regards,
    Kouji Nishigata
  • 0 in reply to user1201164
    TI__Guru* 94781 points
    Kouji,
    by setting the region as strongly ordered, they are essentially disabling the write buffering that the MMU could perform when the region was set to "device memory". All the writes should have been seen on the interface, but they would have probably come in bursts. In the case of strongly ordered memory, you would see all the writes as single accesses.

    Regards,
    james
  • 0 in reply to JJD
    Expert 1770 points

    HI, James

    Thank you for the reply.

    Now I'm looking at what kind of access occurs on the bus depending on memory type.

    In this case, since writing to the same address is done, I think that burst transfer will not occur even with "device memory" setting.

    Also, since there are watching the bus with an oscilloscope, I think that there is no reason to say that the waveform of the write can not be seen even if it is a burst transfer.

    Best Regards,

    Kouji Nishigata

  • 0 in reply to user1201164
    Expert 1770 points
    HI,

    I was able to confirm about the MMU setting when writing was skipped.
    "Normal memory", but the cache is OFF.
    Is it possible that specifications will skip writing in this state?

    Best Regards,
    Kouji Nishigata
  • 0 in reply to user1201164
    TI__Guru* 94781 points
    You'll need to give more details on the MMU setting. I think "normal memory" can be cacheable/noncachable, shared/non-shared, write-through/write-back, etc. Most likely, if you are not seeing all the writes on the bus, there is probably a cache in between that is caching the writes.

    Regards,
    James
  • 0 in reply to JJD
    Expert 1770 points

    Hi, James

    Thank you for your answer.
    This is a customer's board, so I have not verified it myself.
    However, they said that the cache was turned off. Actually Read seems to have been done for several times, so I think that it is not wrong.
    Therefore, I think that the setting of write-through / write-back also has nothing to do with it. (For this setting, I realize that the cache is ON)
    Is it possible to skip the output of write, with access to GPMC, with the cache set to OFF with "normal memory" setting?

    Best Regards,
    Kouji Nishigata

  • 0 in reply to user1201164
    TI__Guru* 94781 points
    Kouji, with all cache levels disabled, i don't see how a write can be missed on the external interface. They should be able to see all of the writes on the scope.

    Regards,
    James
  • 0 in reply to JJD
    Expert 1770 points
    HI, James

    Thank you for answering.
    It is also said that WRITE will not be skipped when the cache is OFF as well.
    Anyway, I will close this question once.

    If customer want to check the details of this phenomenon, ask the MMC settings etc and open it as a new MMU question.

    Best Regards,
    Kouji Nishigata