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

A HPI issue in C6747

Jackson Lin
Prodigy 50 points


We are testing the HPI and are having a trouble. We run in both HPI boot and ROM boot mode on the C6747.
Some initilization done are shown bellow:
1. Setup Pin multiplexing for HPI.
2. Configure HPIENA bit to 1 and HPIBYTEAD to 1 in the chip configuration 1 register (CFGCHIP1).
3. Setup HWOB bit to 1 in HPIC. Also, Setup DUALHPIA bit to 0.
4. Check HPIRST bit in HPIC. And it is right that HPI is release from reset.

Here is what seems to work so far:
1. The host device can write a value to HPIC/HPIA and read back this value. It works well.
2. We try to write DSP internal memory. It works well.

But we have a trouble in reading back from DPS internal memory and registers.
Reading low 16 bits back from DSP internal memory always shows 0.
And reading high 16bits seems to be unstable. The value is variable. Sometime it shows correct value, sometimes it shows 0.
 
For example, we write the memory location 0x11800000 with the value 0x12345678.
But, reading the value from the memory location 0x11800000 shows 0x12340000 or 0x00000000.

Could anyone give any suggestions for this?

thanks in advance,

Jackson

  • 0
    TI__Expert 5955 points

    Hi,

    You had said that the host can write to HPIA but I just want to make sure that the host writes the whole 32 bits, for example, can you try to write to the HPIA with a value of 0x1180_0004? If host write and read the LSW are not working then you might want to check the HHWIL signal and its timings.

    Thanks,

    Tai Nguyen  

  • 0
    TI__Guru*** 125430 points

    Jackson Lin said:
    For example, we write the memory location 0x11800000 with the value 0x12345678.

    In this case what do you see when connecting with JTAG and inspecting address 0x11800000?  Did the write complete correctly?  If you then use CCS to replace that data with 0xdeadbeef do you read back 0xdead0000?  It might provide some clues to know more specifically if the failures are with respect to reads, writes, or both.

  • 0 in reply to Brad Griffis
    Prodigy 50 points

    Brad Griffis said:

    For example, we write the memory location 0x11800000 with the value 0x12345678.

    In this case what do you see when connecting with JTAG and inspecting address 0x11800000?  Did the write complete correctly?  If you then use CCS to replace that data with 0xdeadbeef do you read back 0xdead0000?  It might provide some clues to know more specifically if the failures are with respect to reads, writes, or both.

    [/quote]

    Thanks for your responses.

    We did two things that you suggested below:

    We are connecting with JTAG and inspecting address from 0x11800000 to 0x11801000. Those values from address 0x11800000 to 0x11801000 are all correct as same as those we wrote to. 

    We use CCS to replace that data with 0xdeadbeef, and read back 0xdead0000 via HPI by host.

    It is a big change of reading failures, but we have no clues for this.

    What do you think about this?

    Jackson

  • 0 in reply to Tai Nguyen
    Prodigy 50 points

    Tai Nguyen said:

    You had said that the host can write to HPIA but I just want to make sure that the host writes the whole 32 bits, for example, can you try to write to the HPIA with a value of 0x1180_0004? If host write and read the LSW are not working then you might want to check the HHWIL signal and its timings.

     

    Thanks for your reply.
    We write to the HPIA with a value of 0x1180_0004, then read HPIA value the same as write.
    We check the HHWIL signal to follow TMS320C674x HPI user's guide timings.
    What do you think?
    Could you provide a sample code for HPI access?

    Jackson

  • 0 in reply to Jackson Lin
    TI__Guru*** 125430 points

    Please post a screenshot from a logic analyzer of what's happening on the bus.  For example, perhaps the data is coming out of the 6747 but the timing is wrong on the host and so it's missing part of it.  Or perhaps the logic is wrong from the host causing the 6747 not to output half of the word.  It will be much easier to tell from a screenshot of a read transaction.

  • 0 in reply to Brad Griffis
    Prodigy 50 points

    Brad Griffis said:

    Please post a screenshot from a logic analyzer of what's happening on the bus.  For example, perhaps the data is coming out of the 6747 but the timing is wrong on the host and so it's missing part of it.  Or perhaps the logic is wrong from the host causing the 6747 not to output half of the word.  It will be much easier to tell from a screenshot of a read transaction.

    Thanks for your reply.

    Two steps that we do are described as bellow:

    First, we write the memory location 0x1180FBAC with a value 0x12345678.

    Second, reading the memory 0x1180FBAC shows a value 0x12340000.

    Best Regards,

    Jackson

  • 0 in reply to Jackson Lin
    TI__Guru*** 125430 points

    I'm having great difficult seeing the images -- I think the forum resized them!  Can you zip the two images, then click on the "Options" link and attach the zip file there?  Thanks. (Sorry, to make you post them twice!)

  • 0 in reply to Brad Griffis
    Prodigy 50 points

    Brad Griffis said:

    I'm having great difficult seeing the images -- I think the forum resized them!  Can you zip the two images, then click on the "Options" link and attach the zip file there?  Thanks. (Sorry, to make you post them twice!)

     

    Thanks for your reply.

    I did it as you said.

    1425.HPI issue.zip

    Jackson

  • 0 in reply to Jackson Lin
    TI__Guru*** 125430 points

    Jackson,

    You are not properly observing /HRDY.  For the most part the device will be ready immediately for writes since the data just gets stuffed into a FIFO, but for reads there is a delay while the data is being fetched from memory.  So for both reads and writes it's important, but you're more likely to see issues on the read side because a longer "not ready" delay is expected.

    I have marked up your read timings to show you precisely what I'm describing.

    Best regards,
    Brad