• State TI Thinks Resolved
  • Locked Locked
  • Replies 16 replies
  • Answers 2 answers
  • Subscribers 98 subscribers
  • Views 3334 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.

BE0n,BE1n(Byte enable) signals specification of AM335x ?

shigehiro tsuda
Mastermind 9490 points

Hi,

I confirm it in AD multiplex of 16bit of GPMC in AM335x.
The BE0n/BE1n(byte enable) terminal is the following output.
①Lower byte access
BE0 low:BE1 high
②Higher byte access
BE0 high:BE1 low
③In the case of word access
BE0 low:BE1 low

It does not have any problem that BE0,BE1 signal becomes low active.
BE0 becomes low at the same time as CS becomes high.
However, BE1 does not change at the same time as CS becomes high and seems to maintain the value.

The above according to specifications of AM335x will work?
Because the timing of the details does not write it to see TRM and a data sheet of AM335x either, I ask you a question.

The following wave pattern becomes CS,BE0,BE1 from the top.

case ②Higher byte access

case  ①Lower byte access

Best Regards,
Shigehiro Tsuda

  • 0
    TI__Guru**** 393215 points
    Hi,

    I see nothing wrong with these waveforms. The BE signals should be at valid state when CS is active.
  • 0 in reply to Biser Gatchev-XID
    Mastermind 9490 points

    Hi Biser,

    Thank you for quick reply.

    Sorry, an answer became slow.

    I understand that  the BE signals should be at valid state when CS is active.

    But I ask you a question if I measure waveform because it was a phenomenon unlike TRM.

    I do the following setting, but please tell me whether such a wave pattern may be output by mistake.

    ①gpmc setting

    mw.l 0x50000078 0x00000F08
    mw.l 0x50000060 0x00001200
    mw.l 0x50000064 0x00101000
    mw.l 0x50000068 0x00030301
    mw.l 0x5000006c 0x10041004
    mw.l 0x50000070 0x000C1010
    mw.l 0x50000074 0x08070280
    mw.l 0x50000078 0x00000F48

    ②data access

    mw.b 0x08000000 0xA0
    mw.b 0x08000001 0xB0
    mw.b 0x08000002 0xA0
    mw.b 0x08000003 0xB0

    Best Regards,

    Shigehiro Tsuda

  • 0 in reply to Biser Gatchev-XID
    Mastermind 9490 points
    Hi Biser,

    I understand that the BE signals should be at valid state when CS is active.
    I think that BE1 is as follows for a wave pattern in case ② Higher byte access.
    CS:high->low->high
    BE1:high->low->high

    However, actually, it is as follows.
    CS:high->low->high
    BE1:high->low->low

    Is a way of thinking a mistake?

    Best Regards,
    Shigehiro Tsuda
  • 0 in reply to shigehiro tsuda
    TI__Guru**** 393215 points

    I understand now.

    Section 7.1.3.3.9.1  of the AM335X TRM Rev. L, comments on BE behavior:

    "When either RDCYCLETIME or WRCYCLETIME completes, if they are not already deasserted, all control signals (CSn, ADV_ALEn, OE_REn, WEn, and BE0_CLEn) are deasserted to their reset values, regardless of their deassertion time parameters.

    An exception to this forced deassertion occurs when a pipelined request to the same chip-select or to a different chip-select is pending. In such a case, it is not necessary to deassert a control signal with deassertion time parameters equal to the cycle-time parameter. This exception to forced deassertion prevents any unnecessary glitches. This requirement also applies to BE signals, thus avoiding an unnecessary BE glitch transition when pipelining requests.

    If no inactive cycles are required between successive accesses to the same or to a different chip-select (GPMC_CONFIG6_i[7] CYCLE2CYCLESAMECSEN = 0 or GPMC_CONFIG6_i[6] CYCLE2CYCLEDIFFCSEN = 0, where i = 0 to 3), and if assertion-time parameters associated with the pipelined access are equal to 0, asserted control signals (CSn, ADV_ALEn, BE0_CLEn, WEn, and OE_REn) are kept asserted. This applies to any read/write to read/write access combination.

    If inactive cycles are inserted between successive accesses, that is, CYCLE2CYCLESAMECSEN = 1 or CYCLE2CYCLEDIFFCSEN = 1, the control signals are forced to their respective default reset values for the number of GPMC_FCLK cycles defined in CYCLE2CYCLEDELAY."

  • 0 in reply to Biser Gatchev-XID
    Mastermind 9490 points

    Hi Biser,

    Thank you for quick reply.

    Is BE1 same, too?
    There is the description of BE0, but there does not seem to be the description of BE1.


    GPMC_CONFIG6 is the following setting.
    0x50000074 0x08070280
    CYCLE2CYCLESAMECSEN: 1h = Add CYCLE2CYCLEDELAY
    CYCLE2CYCLEDIFFCSEN: 0h = No delay between the two accesses
    CYCLE2CYCLEDELAY: 2 2h = GPMC_FCLK cycle

    Is it all right if I set following CYCLE2CYCLEDELAY without delay?
    CYCLE2CYCLESAMECSEN: 0h = No delay between the two accesses
    CYCLE2CYCLEDIFFCSEN: 0h = No delay between the two accesses
    CYCLE2CYCLEDELAY: 2 2h = GPMC_FCLK cycle

    I did not understand the intention of the answer well.


    Please tell me whether the set point of the GPMC_CONFIG6 register is wrong.
    It is normal for a wave pattern, and will it be not to be the following output?
    BE1:high->low->high

    Best Regards,

    Shigehiro Tsuda

  • 0 in reply to shigehiro tsuda
    TI__Guru**** 393215 points
    If you don't insert CYCLE2CYCLEDELAY the BE0/1 signals will not be deasserted between successive accesses.
  • 0 in reply to Biser Gatchev-XID
    Mastermind 9490 points

    Hi Biser,

    Thank you for quick reply.

    I confirmed it by the following setting.
    CYCLE2CYCLESAMECSEN: 0h = No delay between the two accesses
    CYCLE2CYCLEDIFFCSEN: 0h = No delay between the two accesses
    CYCLE2CYCLEDELAY: 2 2h = GPMC_FCLK cycle


    As a result, a wave pattern of BE1 does not have a change.

    When CS varied from active to inactive, is it specifications that there is not a change BE1 (a value is maintained)?

    Best Regards,

    Shigehiro Tsuda

  • 0 in reply to shigehiro tsuda
    TI__Guru**** 393215 points
    If you don't enable the delay there will be no change of the BE0/1 value.
  • 0 in reply to Biser Gatchev-XID
    Mastermind 9490 points
    Hi Biser,
    Thank you for quick reply.
    Regardless of the delay, BE1 does not change.
    Is it specifications of GPMC of AM335x?

    Best Regards,
    Shigehiro Tsuda
  • 0 in reply to shigehiro tsuda
    TI__Guru**** 393215 points
    What is the type of access when BE1 doesn't change? 8-bit or 16-bit? Even address or odd address? Read or write?
  • 0 in reply to Biser Gatchev-XID
    Mastermind 9490 points

    Hi Biser,

    Thank you for your reply.

    I reply your question.

    device type:16bit

    access : 8bit

    write access

    odd address:

    waveform of "case ②Higher byte access"

    even address:

    waveform of "case  ①Lower byte access"

    In the case of read access,BE1 does not have the change and  BE1 holds low.

    I confirm it in the following command of u-boot.

    ①gpmc setting

    mw.l 0x50000078 0x00000F08 
    mw.l 0x50000060 0x00001200 
    mw.l 0x50000064 0x00101000 
    mw.l 0x50000068 0x00030301 
    mw.l 0x5000006c 0x10041004 
    mw.l 0x50000070 0x000C1010 
    mw.l 0x50000074 0x08070280 
    mw.l 0x50000078 0x00000F48

    ②data access

    mw.b 0x08000000 0xA0
    mw.b 0x08000001 0xB0
    mw.b 0x08000002 0xA0
    mw.b 0x08000003 0xB0

    I think that you understand it if I check the operation with evaluation boards.
    Can you confirm it with an evaluation board?
    Or will you confirm whether it is specifications of AM335x in your factory team?

    Best Regards,

    Shigehiro Tsuda

  • 0 in reply to shigehiro tsuda
    TI__Guru* 85990 points

    Shigehiro, i think in general the control signals will act differently during non-active cycles (when CS is high) depending on pending transactions.  This is outlined in the TRM excerpt that Biser gave earlier. 

    Are you experiencing any error in functionality?


    Regards,

    James

  • 0 in reply to JJD
    Mastermind 9490 points
    Hi James,

    Thank you for your reply.
    Can you have you explain the following parts a little in greater detail?
    "depending on pending transactions"
    Please tell me what "pending transactions" mentioned above means.

    Best Regards,
    Shigehiro Tsuda
  • 0 in reply to shigehiro tsuda
    TI__Guru* 85990 points

    Shigehiro,

    The controller may pipeline certain transactions to gain greater efficiency on the interface.  So depending on the sequence of accesses that is necessary on the interface, there may be, for example, back to back reads in which you won't see the control signals deassert in between cycles.  In other occasions, the you may see the control signals deassert.  It just depends on what transactions preceded it and succeed it.

    Regards,

    James

  • 0 in reply to JJD
    Mastermind 9490 points

    Hi James,

    Thank you for quick reply.

    Will the wave pattern of BE1 when CS does deassert by adjustment to extend the following timings than current setting change?
    ①WRCYCLETIME
    ②CSOFFTIME

    I do not connect the present conditions, a device of the opposition.
    Will this be connected with a wave pattern of BE1?
    Because your answer writes it as follows, I am interested.
    "back to back reads in which you won't see the control signals deassert in between cycles"

    Best Regards,

    Shigehiro Tsuda