C6747 HPI

Do you have the DSP running during this time, or is it halted in CCS? It probably does not matter, but it would be an interesting datapoint to confirm it both ways.

The timing diagrams in the datasheet make it look like HPIRDY is normally low, indicating ready. It will go high (not ready) during the read of the low half-word while the UHPI fetches the data. This does not at all seem to be what you are seeing, so I would suspect the UHPI peripheral is possibly not properly powered or clocked or enabled.Be sure that the UHPI is specifically enabled in the PSC1 register; this may occur in the GEL file or in your code, but the reset state is to be disabled which turns off the clock.

Or you are not looking at the right pin for HPIRDY. Your host should not be completing the read operation without seeing HPIRDYn=0.

It does sound like you have most everything connected correctly from what you have observed so far, but it would be worthwhile to check and double-check the pins and the waveforms to make sure you are meeting the timing requirements.

Hi Randy,

Thanks for your reply.

RandyP said:

Do you have the DSP running during this time, or is it halted in CCS?

We have tried both ways - the result is the same.  We flashed a program to serial eeprom and executed from that on boot up and also used CCS and JTAG to download and run code.

RandyP said:

... so I would suspect the UHPI peripheral is possibly not properly powered or clocked or enabled.Be sure that the UHPI is specifically enabled in the PSC1 register; this may occur in the GEL file or in your code, but the reset state is to be disabled which turns off the clock.

We rechecked and verified that the UHPI peripheral is enabled, powered, and clocked.  Note that if any of these operations were not done properly, we would NOT be able to read and right to HPIC or the read/write address registers.

I also rechecked that the pins are all configured correctly in the pinmux registers.

What would help is if we had a program that was known to properly initialize the UHPI for operation.  Then I could build it and load it on our target to determine if the problem is something in s/w or h/w.  Can you provide such a program?  For example, the HPI bootload program that is stored in L2 ROM?  Can we have the source code for this?  Then I can build it and modify it for our target and use it for debugging our target.  If not, just any small program that you have confirmed will properly operate the UHPI from the DSP side.  Our target configures L2 as all memory so our program will run completely on-chip.

Thank you for your help.

Mike

Mike,

One quick thing to check is whether you are configued for 32bit word addressing or byte addressing.

If you have not configured CFGCHIP1[HPIBYTEAD]=1 then the HPI will operate using word addresses rather than byte addresses.  Since your host is most likely writing to byte addresses then all of your code would end up in the wrong location.

This is described in a related forum post: http://e2e.ti.com/support/dsp/tms320c6000_floating-point_dsps/f/115/p/12218/47617.aspx#47617

See section 3.9 of HPI user guide for more details.

http://focus.ti.com/general/docs/litabsmultiplefilelist.tsp?literatureNumber=sprufm7c

Cheers,

Aaron

Thanks Aaron,

We did realize we needed to set the HPIBYTEAD as you indicated but it does not solve our problem.  All reads from HPID are 0 regardless of the setting of this bit (but we do now configure this to 1 as part of our HPI initialization).

Mike

There is nothing that can be run on the DSP that will operate the HPI. The HPI is a slave port from an external host to the DSP.

What device are you using as the HPI host?

You said that the HPIRDYn is never showing ready. It should normally be low, showing ready, all the time. It will go high for a short time during reads and possibly writes, but if it is never low (ready), then that points to a configuration problem or pin identification problem.

If you can put the C6747 into HPIBOOT mode and then (after doing the simple host configs to HPIC/HPIA) try writes and reads to L2 memory. The ROM will be turning on everything it needs to turn on to enable HPI activity.

The next thing to look at will be the collected waveforms on the HPI control and address lines.

Hi Randy,

By operate I mean a small piece of code that will configure the deivce pins for HPI, set the HPI enable bit, power-on the module, etc., etc.  This must be part of what the HPI boot load code does so that is why I am asking for the source code for this.  Can you provide this or something similar?  I suspect that I am either not configuring a register correctly or that some part of my code is changing a configuration.  I think I could find the problem if I had a good reference with which to compare.

The host devide we are using is a Motorola ColdFire.  The control/data lines are going through a CPLD to facilitate timing and logic of the HPI.

We are working on a screenshot of a logic analyzer showing the control/data lines.  I'll post that later today.

Mike

Below are some logic analyzer captures.  We can show a successful and unsuccessful HPI memory read.   The successful read is achieved by invoking the HPI bootload program.  We do this either by power recycle of the board with the bootcfg pins set for HPI boot or simply by using CCS to set the PC to 0x00700000 (start of L2 ROM) and running the target (bootcfg pins set to HPI boot).  When we use this procedure, we can even halt the program, download via JTAG our application program, run, and still have successful HPI reads.  But if we power cycle the board and do not allow the HPI boot program to execute - just run our application program, we cannot successfully read the DSP memory.

This first screen shot shows a successful read of memory 0x01E10000 (UHPI Rev. ID).  The data at this location is 0x4421210A.

Timing also looks good.

This next screenshot is when the application code is running w/o having run the HPI bootload program first (e.g. a normal load and execution of our application code):

Note that as soon as the CS is asserted, HP_RDY is deasserted until CS is deasserted.   In this case reads are always 0 and RDY is never asserted. BUT we

can correctly read the HPIAR/HPIAW register which in our test case is 0x01E10000.  Here is a screenshot of that:

We are reading back the HPIAR/HPIAW register.  The value is correct but HP_RDY is de-asserted.

If it helps I can send you our small program that merely configures the HPI and then falls into a while loop and

then you can tell me what's missing.

thanks,

Mike

RandyP said:

For step 4, write HPIC.HPIRST = 0 to reset the UHPI.

Can you be more specific.  I don't see a HPIRST bit in the HPIC register.  Here is a cut/past from the C6747 HPI User's Guide (sprufm7c):

        Bit Field              Value                   Description
31-12 Reserved           0                       Reserved
11 HPIASEL                                          HPI address register select bit. When DUALHPIA = 1, the HPIASEL bit is used to select the HPI
                                                                  address register to be accessed.
                                      0                   Selects the HPI write address register (HPIAW).
                                     1                    Selects the HPI read address register (HPIAR).
10 Reserved             0                    Reserved. Always write 0 to this bit.
9 DUALHPIA                                         Dual HPIA mode configuration bit. The CPU can access both HPI address registers separately,
                                                                 regardless of the DUALHPIA setting. (Regardless of this bit, dual HPIA mode is implied when the
                                                                 CPU has ownership of the HPI address registers).
                                     0 The two HPI address registers (HPIAW and HPIAR) operate as a single HPI address register in
                                           terms of host accesses.
                                   1 Dual HPIA mode operation is enabled.
8 HWOBSTAT                               HWOB status. The value of the HWOB bit is also stored in this bit position. A write to the HWOB bit
                                                        also updates HWOBSTAT.
                                  0     HWOB bit is logic 0.
                                 1     HWOB bit is logic 1.
7-5 Reserved         0                Reserved. Always write 0 to this bit.
4 FETCH                         Host data fetch request bit. Only the host may write to FETCH. When a host writes a 1 to FETCH, a
                                        request is posted in the HPI to prefetch data into the read FIFO. Host and CPU reads of FETCH
                                       return a 0.
3 Reserved            1 Reserved
2 HINT                                        Processor-to-host interrupt. The CPU writes a 1 to HINT to generate a host interrupt. HINT has an
                                                      inverted logic level to the UHPI_HINT pin. The host must write a 1 to HINT to clear the UHPI_HINT
                                                    pin; writing a 0 to HINT by the host or processor has no effect.
                               0 No effect.
                            1 A CPU write generates a host interrupt (UHPI_HINT signal goes low). A host write sets the
                                    UHPI_HINT signal high (clears the interrupt).
1 DSPINT                                     Host-to-processor interrupt. The host writes a 1 to DSPINT to generate a processor interrupt;
                                                      writing a 0 to DSPINT by the host or processor has no effect.
                             0 No effect.
                            1 A host write generates a processor interrupt.
0 HWOB                                        Halfword ordering bit. HWOB affects both data and address transfers. HWOB must be initialized
                                                         before the first data or address register access.
                            0 First halfword is most significant.
                          1 First halfword is least significant.

I can't find any reference to "HPIRST" in the document.  Please advise...

Mike

What is very odd is that I was definitely told that this is what should be done. I got feedback from the ROM team that this is bit 7, which is of course reserved. And writing 0 to it is what you are always supposed to do, so there is no way that this should cause a reset. It might release a reset, but there was no mention of writing a 1 to this bit earlier.

I have theories, but none of them matter unless we can get you running.

If you have not done so already, please try all the other steps to see if you can get it to work without worrying about bit 7.

If it does not work, still, try setting bit 7 as if it is step 0, then clear bit 7 at step 4.

If that does not work, send us your small program.

Have you written to the KICK registers?  The pin muxing registers and CFGCHIP registers are not writeable without first writing the proper sequence to the KICK registers.  Perhaps you've already done so, but I didn't see any mention of these registers anywhere in the thread.

My other suggestion would be to dump the HPI registers (for starters) for the case where things work (HPI boot mode) and where they don't work in order to see what is different in terms of register configuration.

Hi Randy,

I appreciate your continued input.   I spoke with our area TI support guy Aaron and we also talked with a engineer named Tommy from Houston who is now looking into this.  He didn't think this bit was used on a C6747.  So I guess this needs to be confirmed within TI.  I sent my program to Tommy via Aaron.  I also thought maybe writing a GEL script to set up the HPI operation would be a good idea.  Could you write this out?  Or I could do that and post it for your review (and possible test).

Mike

Brad Griffis said:

Have you written to the KICK registers?  The pin muxing registers and CFGCHIP registers are not writeable without first writing the proper sequence to the KICK registers.  Perhaps you've already done so, but I didn't see any mention of these registers anywhere in the thread.

My other suggestion would be to dump the HPI registers (for starters) for the case where things work (HPI boot mode) and where they don't work in order to see what is different in terms of register configuration.

Brad,

Are you sure we need the KICK registers to modify the pinmux registers?  I know this is done in the EVM6747 GEL script which is executed on startup even for our target h/w.  I'll have to double check this, BUT I can verify the pinmux registers are getting set when I halt the program using the JTAG emulator and view registers.  Also note that if the pinmux registers weren't getting configured properly, we would not have any activity on the HPI (recall in my issue the host device can indeed read/write the HPIC and HPIAR/HPIAW regsiters).

I also tried your other suggestion.  I did a memory dump of both cases.  I did a dump of the PSC1 registers, PSC0 regsiters and SYSCONFIG registers for both cases and compared them.  The matched exactly except for the BOOTCFG register which showed that the bootconfig pins were set for HPI boot mode in one case and SPI flash boot in the other.  This matches the jumper settings of our h/w for both those cases so it is expected. 

Now, we do see some bits in the HPIC regsiters that are not consistent with the HPI User's Guide but these bits are listed as reserved so we figured their setting was irrelevant.  Is that so?

Mike

Mike said:

Now, we do see some bits in the HPIC regsiters that are not consistent with the HPI User's Guide but these bits are listed as reserved so we figured their setting was irrelevant.  Is that so?

Which bits and how do they show up in the hardware?

How does your code handle these bits, i.e. do you do a read-modify-write and leave the value alone or do you just write a specific value?

Brad,

How come the look is different now in the E2E forum?  It seems more difficult to read; not the nice layout I was used to.  Did they change something last night?

I just did a test for the HPIC.  I powered up our board in JTAG boot mode and connected the JTAG. This ran the evmomapl137_dsp.gel function "OnTargetConnect".  This function will turn on power and clock to HPI module but nothing else (no enabling or configuring of the HPI pinmux).  In fact the pinmux registers get configured to use in EMIFA mode.  I used the view -> registers-> HPI0 to look at the HPI registers.  The value of HPIC is 0x000000C0.  So bits 7 and 6 are set.  In the User's Guide they are described as Reserved bits with no other explanation.  So we leave these alone.  We do not write to them.  The guide (sprufm7c) states that out of reset they should be 0.  I think you can see this behavior on the L137 EVM if you have one.  The guide also states the only bits the DSP (e.g. CPU) can write in HPIC register are bits 7,2, and 1.  So I don't even think the DSP can change the value of bit 6.  Now bit 7 seems interesting.  This is the bit Randy says must be written to in order to reset the HPI.  But the Users Guide makes no mention of this and another TI engineer (Tommy) told me the reset step was not needed (HPIRST is unused) in the C6747.

Okay, now I will cycle power on the board with the bootmode pins set for HPI boot.  I remove the GEL file so nothing gets executed upon board connect.  I perform the connect operation in CCS and the HPI boot program which had been running and waiting for interaction from the host device halts.  I view the HPIC register.  This time the value is 0x00000044.  Bit 7 is now 0.  The HINT bit is also set but this is expected when the HPI bootload program executes.  So why is bit 7 getting cleared to 0 by the HPI bootload program?  I'm suspecting now that it has a purpose like Randy mentioned.  Can someone at TI verify the purpose of Bit 7 and explain why its value changes in HPI boot mode?

Mike

I hope I'm just seeing the site under construction cause it looks terrible!

Anyway, your suggestion worked.  When we clear bit 7 from 1 to 0, the HPI becomes operational!!  Kudos to Randy for being the (only) one that mentioned a HPIRST bit.  I'll put up another post soon with a full explanation and verify the answer.

Mike

I am glad you got it to work. We need to get this figured out inside TI and get the documentation corrected. Your exact code sequence will be very helpful.

Thanks for the great summary and for bearing with us as we worked through the issue.

On a side note I still have not seen a single "odd " thing with the forums so I wonder if you are having some kind of browser issue.  Maybe you need to clear your cache or something.  Perhaps try a different browser as a sanity check.

Brad Griffis said:

On a side note I still have not seen a single "odd " thing with the forums so I wonder if you are having some kind of browser issue.  Maybe you need to clear your cache or something.  Perhaps try a different browser as a sanity check.

Yep - Just had to clear the cache.  I had never run across that before.  Thanks for the internet browser support! 

Tell your boss I said he should buy you lunch for providing browser support as well as TI support!

Mike