TMS320C6747: communication using HPI interface between C6747 and F28335

Daniel Wolfgruber17

Part Number: TMS320C6747

We are using XINTF on F28335 to communicate with HPI on C6747. We are sending/reading multiple 32-bit values to/from C6747 memory with autoincrement mode.

Physically, the data is transmitted correctly in both directions (Bus analysis with scope and logic analyzer; correct timing and signal quality). However, it can happen that the data (written or read) from the C6747 is not stored at / read from the correct address (but the data itself is correctly transmitted).

Example:
Write to Addresses in autoincrement mode:
- Value0 = 0x1
- Value1 = 0x2
- Value2 = 0x3

Two consecutive autoincrement reads could lead to:
- Value0 = 0x1
- Value1 = 0x3 (instead of 0x2)

over 5 years ago

0 Cvetolin Shulev-XID over 5 years ago

TI__Guru 65405 points

The team is notified. They will post their feedback directly here.

BR
Tsvetolin Shulev

0 Lawrence Ronk over 5 years ago in reply to Cvetolin Shulev-XID

TI__Intellectual 2810 points

Thank you for providing the information. We are reviewing the data you provided with our HW engineers and we plan to come back to you with some suggestions or ideas by Tue of next week.

Regards,
Lawrence

0 RandyP over 5 years ago

TI__Guru* 84110 points

Daniel,

If you write with auto-increment but read with non-increment mode, do you get the same results? If you do the other and write with non-increment but read with auto-increment, do you get the same results?

If you repeat the failing auto-increment reads, will you get the same wrong values?

You said the failure 'can happen'. Could you quantify the chances and conditions when it passes or fails? Is the probability of failure sensitive to temperature or voltage? Do you have multiple boards that all have the same or similar failure rates?

If you inspect the C6747 memory using JTAG & CCS, do you see the values as written correctly or do you see the values the same as what you see from the auto-increment reads?

What is the C6747 doing during the time of the UHPI accesses? Is it running code that is actively exercising the device's various memory areas?

What physical addresses are you using in your tests above?

My biggest concern would be the proper use of the UHPI_HRDY signal. There can be cases where internal activity causes the UHPI to stall for a short time when trying to access memory against internal conflicts.

Regards,
RandyP

0 Daniel Wolfgruber17 over 5 years ago in reply to RandyP

Prodigy 85 points

Randy,

Sorry, for the late reply ... we had a lot to test in the previous weeks but it seems we found something.

At our C6747 PCB we are routing the observe-clock signal from the C6747 to a testpin. The observe-clock signal was always active and we could probe the 24MHz of the oscillator. By deactivating the according GPIO, we were able to get rid of false increments.

We also got the information from the High-Frequency Oscillator and PLL Terminal Functions datasheet
(4) Note: The CLKOUT clock output is provided as PLL observation clock, and is provided for debug purposes only. It may be routed to a test point, but should never be connected to a load.

--> However, it says that the routing to a Testpin is allowed as long as no load is attached, which was not the case.

____

To answer your previous questions:

- it does not matter if I use auto-increment or not, when not using autoincrement sometimes the same word is read twice ... High-Word == Low-Word
- also no difference if we only use auto-increment in one direction
- the failure can be provoked more often at higher temperatures, so it is sensitive to temperature
- we have multiple boards with similar error rates, but there are some that are producing much more errors than others
- when read-errors occurred, we checked the C6000 memory and the values there were always correct
- in our test FW, the C6747 does not do anything. It is just configured for HPI use and then used as external memory for the F28335, so no interference should be possible
- Physical Addresses in C6747: 0x8001F000 --> 0x8001F400

Regarding the UHPI_HRDY signal I will post a related question, because now we see another issue.

BR, Daniel

0 Mark Mckeown over 5 years ago in reply to Daniel Wolfgruber17

TI__Mastermind 29270 points

HI Daniel,

Are you able to move past this issue now?

To recap for the benefit of others on the forum... Keeping the CLKOUT/OBSCLK output pin enabled was causing the HPI data strobe inputs to "see" an edge, leading to an inadvertent increment of the HPI autoincrement counter. This is likely to have been caused by ground bounce from the OBSCLK pin, which is physically close to the HPI input pins in the package. It might have been made worse by the slower edge rate of the HPI data strobe due to it being routed to multiple devices on the board and seeing their reflections on the transmission line. This probably extended the time that the strobe signal lingers around the threshold region of the input buffer, increasing the chances that a OBSCLK edge could couple into the input buffer. The OBSCLK buffer is strong. Disabling the OBSCLK signal resolved the autoincrement error.

Documentation states that the OBSCLK pin must not be used except for debugging purposes (checking PLL clock frequencies), but it should probably add that CLKOUT should not be used during mission mode of the application to avoid this type of issue.

Please correct me if I am wrong.

Regards,
Mark

0 Daniel Wolfgruber17 over 5 years ago in reply to Mark Mckeown

Prodigy 85 points

Yes, the OBSCLK signal seems to have led to the increment errors. Thank you.

Processors

Processors forum

TMS320C6747: communication using HPI interface between C6747 and F28335