cannot read first 2-bytes from host during C6747 HPI boot

I never saw a response to this suggestion from the previous thread.

Brad Griffis said:

 Performing another write to HPIAW will cause the FIFO to be emptied immediately.  Perhaps try that and then poll for the write to complete, i.e. multiple reads if necessary.

Brad Griffis said:

I never saw a response to this suggestion from the previous thread.

Brad, you're right, I've confused a bit. Anyway, I try to perform a write to flush the HPI FIFO and then a poll with multiple reads but it still does not work. To be more precise, here're the steps I'm following (from the Host view):

1. Write a single 32-bit data (0x11804000) to HPIAW at address 0x11800000 (the entry point writing)
2. Write another 32-bit data to empty the FIFO immediately (i.e. same data at the same address than step 1.)
3. Poll - Here, reading data from HPIAR results in 0x00004000 instead 0x11804000
4. Repeat step 3. (multiple reads) with no success (0x00004000 again)

This only happens during the boot process. In contrast, when my C6747 application starts I can perform HPI readings without problems. Well, I hope I've explained that clearly.

Regards,
Gaston 

Hello Brad, have you got any news about the last post? I found a little workaround so I'm able to load and verify the image through hpi successfully. I'd just like to know if I'm accessing to hpi in the wrong way or there is a bug during the boot process. 

Regards,
Gaston 

Gaston Schelotto said:

To be more precise, here're the steps I'm following (from the Host view):

1. Write a single 32-bit data (0x11804000) to HPIAW at address 0x11800000 (the entry point writing)
2. Write another 32-bit data to empty the FIFO immediately (i.e. same data at the same address than step 1.)
3. Poll - Here, reading data from HPIAR results in 0x00004000 instead 0x11804000
4. Repeat step 3. (multiple reads) with no success (0x00004000 again)

I was confused by your steps.  In particular you never mention writes to HPID and whether you're doing fixed or auto-incrementing reads/writes.  Here's how I believe it should look:

1. HPIAW = 0x11800000
2. HPID = 0x11804000 (no increment)
3. HPIAW = 0x11800000 (will force /HRDY high to stall until FIFO flushes)
4. HPIAR = 0x11800000
5. Read HPID (no increment)

I believe steps 4-5 above are not necessary because step 3 will stall (/HRDY high) until the data has been written to memory.  You should be able to confirm that behavior with steps 4-5.

Thank you for replying Brad, I believe we're close to find out what's going on. I've gone back to HPI user's guide and I've realized that I was confused with some HPI register names (i.e.HPIAR, HPIAW, HPID). However I'm still performing the HPI accesses in the right way with no success, even by following your last suggestions. Please, let me summarize the steps I'm doing again (better explained)

1. HPIAW = 0x11800000
2. HPID = 0x11804000 (no auto-increment) 
   1. At this point and after connecting the C6747 device target by JTAG I can see 0x11804000 value at 0x11800000. Here's the proof that the value has been written correctly. In addition no matter which increment mode (auto/no-auto) have I set, they both work fine.
3. HPIAW = 0x11800000 (will force /HRDY high to stall until FIFO flushes).
4. HPIAR = 0x11800000
5. Read HPID (no increment)
   1. Here data obtained is 0x00004000 instead 0x11804000.
   2. I repeat steps 4-5 with the same result (do{} loop)

Brad Griffis said:

I believe steps 4-5 above are not necessary because step 3 will stall (/HRDY high) until the data has been written to memory.  You should be able to confirm that behavior with steps 4-5.

I have no problem to write to device memory. Instead the problem appears when I try to read back from this memory (steps 4-5)

What puzzles me most is that HPI works correctly when the device application is running on C6747. In this scenario the host can write / read data through HPI with no errors. Here I have repeated steps 1-3 and data obtained at steps 4-5 has been 0x11804000 as expected.

Regards,
Gaston

Gaston,

Considering that the internal UHPI FIFO's are 32-b wide, I would expect the internal FIFO to *not* misbehave on 16-bit boundaries within a 32-bit aligned access.  Are you able to view the HPI signals on a logic analyzer or scope?  Can you expecially verify that the HHWIL (half-word indicator) is properly toggling for the low and high half-words respectively?

How is your host controller interfaced to the UHPI?  Is it possible that the *first* read has some issue in some logic/statemachine (maybe in an FPGA?) that clears itself after the first access?  Can you add step 4.5 and read back the HPIAR register before beginning HPID read accesses?

Assuming HHWIL and the protocol in general is OK, then in order to rule out FIFO flushing issues, could you try a sequence something like:

1. HPIAW = 0x11800000

2. HPID++ = 0x03020100, 0706050403, ... , 0xFF, FE, FD, FC // 256 Bytes written

3. HPIAW = 0x11800000 // to flush

4. HPIAR = 0x11800000

5. Read HPID++ (64 words, 256 Bytes) w/ auto-increment  // What do you get? Is first word always wrong as before?

Repeat above starting from reset using:

4. HPIAR = 0x11800080

5. Read HPID++ (remainder of buffer, 32 words) // What do you get? Is first word always wrong as before?

Repeat above starting from reset using:

1. HPIAW = 0x11800100

Thanks in advance,
Kyle

Hi Kyle, I've been talking with my customer to get clarification and here's a summary:

• The host processor is a STR912FAW44. This device is not able to latch data (only address) so I had to set UHPI_HDS2n to High and to deassert /assert UHPI_HDS1n manually. I know this is a little fudge but I couldn't find another way to do it. The host is also not able to acknow UHPI_HRDYn.
• UHPI_HCSn is driven by STR9 EMI interface. I've tried to get the control of this line and set it manually during RD/WR transfers with no success.
• Last thing made me think  that internal HSTRBn could be asserted by UHPI_HCSn. Which, according to the HPI user's guide is not recommended.
• Between the host and C6747 HPI there is a 74LVC16245 transceiver to separate HPI bus from STR9 external SRAM memory  Here's a little schema of this configuration:

kcastille said:

Is it possible that the *first* read has some issue in some logic/statemachine (maybe in an FPGA?)

I'm afraid so but why it happens only during boot and not after application starts? I've followed your suggested sequence and I'd like to share some diagrams to get clarification:

kcastille said:

HPIAW = 0x11800000

2. HPID++ = 0x03020100, 0706050403, ... , 0xFF, FE, FD, FC // 256 Bytes written

3. HPIAW = 0x11800000 // to flush

4. HPIAR = 0x11800000

After performing these steps I can see next memory content of C6747:

Which is correct! Now I've followed with next steps

kcastille said:

4. HPIAR = 0x11800000

5. Read HPID++ (64 words, 256 Bytes) w/ auto-increment  // What do you get? Is first word always wrong as before?

Yes, same as before

Here's the timing during last read

It seems there's a misbehave at the first data to be read where UHPI_HRDYn holds to High and then deasserted by the chip select UHPI_HCSn (since I have no control over this line).

I repeated next steps reading 64 and 32 word remaining data with the same results. Your last suggestion (repeat starting from reset with HPIAW=0x11800100) has a worse outcome: The first 4 read bytes are zero. However contiguous data are ok.

Well, I'll try to think more about all this. Please, let me know if you have any ideas.

Regards,
Gaston 

Gaston,

It's illegal to deassert the HSTROBE (effectively HCS in your diagram) while HRDY is 'not ready'.  When does the host latch read response data?  It may be that you're latching the data before it has been fetched and placed on the bus by the HPI.  In general, the very first HPI read access takes longer since the internal bus request has to flow through the SoC.  This is reflected by the HRDY signal. 

To visually verify this, try using a data pattern that sets HD12 (by setting bit 12 and 28 in the memory pattern) so that you can see HD12 transition from 0 to 1 on your waveform.

I'm not quite sure why it works during run time but fails at boot.  One explanation may be that if you're always reading linear addresses, it's only the very first read that has a 'not ready' condition.  After that, the internal FIFO prefetching that the UHPI performs may provide data to the local FIFO such that any subsequent read by the host is able to read directly from the FIFO.  At run-time, are you reprogramming the HPIAW and HPIAR to access (effectively) random locations, or do accesses always proceed linearly?  My guess is that if you reinitialize HPIAW/HPIAR at a later point in time after system boot you'll see the same failure.

If at all possible, you should investigate means to have your host extend it's data access timing dependent on the HRDY signal.

If your host doesn't have a 'ready' signal to control the bus timing then you have two (fairly bad) choices:

1) Make your host strobes slow/wide enough such that you *never* violate the HRDY timing requirement even though you don't have HRDY.  This is dangerous since internal DMA/bus loading will make the HRDY timing variable and new system conditions may lead to cases where the timing is violated.

2) Write to the HPIC.FETCH bit to preload the read fifo.  Then read from HPID after the FIFO is preloaded.  Even this suggestion is problematic as you don't really know when the internal read FIFO has been preloaded.  As in point #1, If you wait long enough it should work, but that timing may change as system conditions change.

Not a great answer, but I hope this helps. 

Regards

Kyle

Kyle,

Sorry for the delay in replying to your comments. I tried to investigate a little more on this issue but I've run out of time. On the one hand I find STR9 EMI documentation difficult to read and a bit imprecise in order to test some configuration options (It came to my mind the TI case and I've realized about its effort to produce and maintain such a quite good documentation!) On the other hand, I'll have to move to other project soon. Therefore only during the boot process, and for data integrity verification, I will read previous 4-bytes as a workaround.

host_hpi_read (c6747_address - 4, read_buffer, byte_size + 4);

So after this call I'will discard the first 4 bytes in the read_buffer.

Thank you and Brad for your patience and understanding.

Regards,
Gaston