• State
  • Locked Locked
  • Replies 10 replies
  • Subscribers 99 subscribers
  • Views 1103 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.

TMS320C6727B: Support UHPI on C6727B DSP

Mike Xia
Prodigy 80 points

Part Number: TMS320C6727B
Other Parts Discussed in Thread: AM3874

From the customer:

We are having some difficulty in communicating between the AM3874’s GPMC port and the DSP’s UHPI port.  We are asking for some support from TI on this matter.  Here is the background…

 

AM3874 GPMC -> 8x C6727B UHPI.  Connection example in the attached image, which is multiplexed half-word.  We have individual CS per DSP.  All other connections are bussed in 2 groups of 4.  All SI has been simulated and is consistent with what we’re seeing on the scope.  Clock is 33.3MHz on CLKIN.  Each DSP has 128Mb (4Mx32) of SDR.  We have used these DSPs before, but in 32-bit mode and with an FPGA.

 

So far we have enabled UHPI boot mode by holding CS and other config pins while releasing reset.  We can read and write HPIA and HPIC, and the data looks correct in the debugger.  We can see writes to HPID go across the bus, but when we read back HPID, HRDY never goes low and we get 0x0.  Our CS low duration for reads is something like 400ns long, which makes me think something in the DSP is not responding.  Are we missing some step before we can access register data through HPID?  The only things we have touched so far have been the parts described here.

 

We also have experienced the bus collision on HWIL during reads.  We have seen this fixed by changing this pin to a GPIO input.  Is this still TI’s suggested solution?  Are there any issues here?

  • 0
    TI__Guru*** 125430 points
    How are the SPI pins configured? Make sure you're configuring SPI0_SOMI = 1 such that BYTEAD=1. Otherwise you need to use word addresses for everything (i.e. take the regular byte address and right-shift by 2). For example, if you don't have that configured correctly right now you might be accidentally writing to reserved memory locations which can hang the bus.
  • 0 in reply to Brad Griffis
    Prodigy 50 points

    SPI0_SOMI (BYTEAD) = 1

    SPI0_SIMO (FULL) = 0

    SPI0_CLK (NMUX) = 0

    We can see the correct values for HPIA in CCS when we read/write addresses,  Is it possible to see HPID in CCS?

    A hung bus definitely sounds like what we're seeing.  On reads, we are keeping CS low for 400ns before we give up on HRDY going low.  Does anything else cause a hung bus?  We are generally trying to read/write UHPI registers at 4300 0000 offset.

  • 0 in reply to Chris Epstein
    TI__Guru*** 125430 points

    When you connect with JTAG, what value do you see in the CFGHPI register, address 0x4000 0008?

  • 0 in reply to Brad Griffis
    Prodigy 50 points

    We were seeing 0x00000011 with the debugger.

    Initially, we had a problem where the debugger was preventing the bootloader from starting and we were simply getting 0x0. We are now removing the debugger each time we need to reinit.

  • 0 in reply to Chris Epstein
    TI__Guru*** 125430 points
    That's the correct value. I wanted to be absolutely certain on the whole BYTEAD topic as I've bumped into that one many many times... It is definitely configured as expected (i.e. to use byte addresses).

    Are you able to connect a logic analyzer to the interface to capture the full timing? I'm concerned you're not meeting all the timing requirements. One specific area of concern relates to your hardware connection where you are using only HCS and have HDS1 and HDS2 statically connected. Take a look at the UHPI_HAS signal. Do you meet the setup/hold requirements?

    To answer your earlier question, there's no way to read HPID from a register. A few other thoughts come to mind for experiments to perhaps understand what's happening:

    1. Can you do a few experiments where you simply write the HPIA register and then check it from CCS? For example, can you successfully write something like 0xdeadbeef to the register? Can you see if you are consistently able to set HPIA to the desired value?

    2. Do UHPI reads and writes both hang the bus?

    3. Can you try accessing internal RAM, e.g. address 0x10000000? Perhaps try writing a pattern using CCS and then reading it back over the bus?
  • 0 in reply to Brad Griffis
    Prodigy 50 points

    I will run these tests as soon as possible.

    Also, we have UHPI_HAS pulled high, so I'm not sure what you want me to check there.

  • 0 in reply to Chris Epstein
    TI__Guru*** 125430 points

    Chris Epstein said:
    Also, we have UHPI_HAS pulled high, so I'm not sure what you want me to check there.

    Sorry, I wrote the wrong signal...  Please look very carefully at the HHWIL signal.  There are a few items:

    1. I want to make sure it is toggling as expected to latch in the appropriate portion of the word.
    2. Please check the timings.  In particular, you need to make sure that HDS1/2, HCNTL0/1, HHWIL, and HRW are valid 5ns before your chip select is asserted.
    3. Please also check the voltage levels using a scope (not logic analyzer) on HHWIL.

    Item #3 relates to the following note in the Data Manual that I just noticed:

    Unless configured as general-purpose I/O in the UHPI module, UHPI_HD[31:17] and
    UHPI_HD[16]/HHWIL will be driven as outputs along with UHPI_HD[15:0] when the HPI
    is read, even though only the lower half-word is used to transfer data. This can be
    especially problematic for the UHPI_HD[16]/HHWIL pin which should be used as an
    input in this mode. Therefore, be sure to configure the upper half of the UHPI_HD bus
    as general-purpose I/O pins. Furthermore, be sure to program the UHPI_HD[16]
    function as a general-purpose input to avoid a drive conflict with the external host
    MCU.

    Also, how do you have the UHPI_HBE signals connected?  This CAUTION relates to that configuration:

    When performing a set of HPID with autoincrementing address accesses
    (UHPI_HCNTL[1:0] = '01'), the set must begin and end at a word-aligned address. In
    addition, all four of the UHPI_HBE[3:0] must be enabled on every access in the set.

    For starters, I strongly recommend driving HCNTL0/1 high (non-incrementing access) to avoid issues like the one above.  Once you get things working you can look to make optimizations.

  • 0 in reply to Brad Griffis
    Prodigy 50 points

    All of our control lines, HRW, HWIL, and HCNTL0/1, are valid 15ns before chip asserts.

    We have UHPI_HBE[3:0] all tied low.

    I am looking at timing info.  Please check my math.  Our CLKIN is 33.3MHz from an FPGA.  Default behavior for SYSCLK2 is: PLL disabled, CLKDIV0 = /1, CLKDIV2 = /2, so SYSCLK is CLKIN/2 or 16.6MHz.  According to FIgure 4-24 for multiplexed writes w/HAS high, we can expect HRDY to assert after CS/Hstrobe assert using the timing spec #35, which is 40*2H+20ns.  This is 2.42ns.  Is this all correct?  I double checked the PLL settings in the debugger. 

  • 0 in reply to Chris Epstein
    TI__Guru*** 125430 points

    Chris Epstein said:
    According to FIgure 4-24 for multiplexed writes w/HAS high, we can expect HRDY to assert after CS/Hstrobe assert using the timing spec #35, which is 40*2H+20ns.  This is 2.42ns.  Is this all correct

    I think that should have been 2.42us instead of 2.42ns.

    Have you been able to spend any more time writing and reading the HPIA register?  I would expect if you can properly write/read that register you should be able to write/read data as well.

    FYI, I'm going to be traveling for a couple days.  It would be great if you could get some screenshots from a logic analyzer showing that you have the signaling and timing correct.

  • 0 in reply to Brad Griffis
    Prodigy 50 points

    Yes, I meant 2.42us.

    Here is a capture where we are running CS entirely too quickly (50ns) and ignoring HRDY.

    1, yellow = HRDY

    2, green = HRW

    3, purple = CS

    4, pink = HWIL

    This is a write to HPIA.  I'm writing 0x00004300 into hpia  using the timing below and it is showing in the debugger as 0x43000000.  I'm assuming that flipping the HWOB bit in HPIC will correct this once we have the interface running correctly.