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 with HPI interface on C6713



We have a product currently in design.  We are using the HPI to transfer data directly into the DSP's memory from a host PC.  We've had a working HPI for several weeks until a couple days ago.  We cannot determine what went wrong to break things.  HPI reads (host reading data from DSP memory) still work flawlessly but HPI writes (host writing data to DSP memory) exhibits the behavior as shown in the below example.  This behavior is solid and repeatable.

For this example lets say we are trying to write data to DSP address 0x80000000 which in our case is SRAM but this behavior is observed at all addresses.   We'll also assume that this example starts with the first HPI access after power-up (thus the garbage at the beginning).  Finally, we are observing the actual value of the memory using Code Composer v4 and a JTAG Emulator.  The table below shows a sequence of HPI writes and the actual memory after each write.  These writes are done individually so there are many seconds in between each write.

HPI Write Value In Memory after Write
0x1 0xYYYY   (garbage due to power-up)
0x2 0xYYYY   (garbage due to power-up)
0x3 0xYYYY   (garbage due to power-up)
0x4 0xYYYY   (garbage due to power-up)
0x5 0xYYYY   (garbage due to power-up)
0x6 0xYYYY   (garbage due to power-up)
0x7 0x1
0x8 0x2
0x9 0x3
0xA 0x4
0xB 0x5
0x0 0x6
0x0 0x7
0x0 0x8

It is obvious that the data is being buffered internally and this buffer is not correctly being flushed.  It seems that once the buffer is full (I would expect it to be 8 dwords according to documentation but it seems to be 6 so maybe once it is 75% full) each new write results in one dword is being flushed and written to memory.  Whatever it is internally (EDMA?) that is responsible for flushing this buffer has stopped working.

The board is still in heavy development so we have been tweaking both hardware and software.  We are not sure what we changed or broke to create this behavior.  Any clues or directional pointers would be much appreciative.

 

David Clark | Senior Software Engineer | C&H Technologies, Inc. | www.chtech.com | 512.733.2621

 

  • Update:  Today we worked on getting an identical board operational and it does not exhibit this problem using the exact same software (host) and firmware (DSP).  So we are pretty certain it is hardware. 

    It is also important to note that the HPI interface works fine.  It is the internal back end (taking data out of the HPI write buffer and sending it to memory) that is the problem.  Either we damaged something internally in the DSP or there is some external signal that is causing this (clock, power, reset, I/O etc.).

    David

  • The second board that was working is now exhibiting the exact same behavior.  It seemed to arbitrarily happen.  In other words, no hardware modification were made.  Any and all clues would be much appreciated.

    David

  • This does sound very odd...

    A couple of questions:

    1. What is the DSP doing during the HPI writes?  Is it halted through CCS, or is it in some sort of while(1) loop?

    2. Have you tried probing the HPI pins to be sure the host is not the one actually sending the garbage data?

    3. Have you tried probing the HRDY pin to asses the status of the HPI?

    Gus

  • David,

    I was wondering if you can tell me what type of hardware interface you used to connect your PC to the HPI ?  We have a DSK and would like to consider using the HPI.

    Thanks,

    Wes