HRDY will be always Low when HPIA Write Access of C5517.

Hi,

 

Could you provide more information on HPI configurations done for this access.

As mentioned in the technical reference manual One reason the UHPI may drive UHPI_HRDY low is a not-ready condition in one of its FIFO buffer. For example, any UHPID access that occurs while the write FIFO is full or the read FIFO is empty may result in some number of wait states being inserted by the UHPI. Is this been checked ?

Also, I am not sure about your last statement “This condition can be confirmed when the DSP of 87MHz, if they were to 174MHz, although the frequency is lowered, occur” could you elaborate ?

 

Other platform related questions that I had are

• I believe that these are custom boards. If so is this behavior observed in other boards too ?
• Is the scenario been tried on TI C5517 EVM ?

 Could you let us know on the above.

 

Regards

Vasanth

thanks

This phenomenon does not occur and they are to be Run by connecting the emulator, it is unlikely to have occurred in the FIFO Full.

When an emulator was connected.
Run : not occur
Free Run : occur

The frequency which occurs
87MHz : Once an hour
174MHz : Once a day


Q:I believe that these are custom boards. If so is this behavior observed in other boards too ?
A:I'm not experimenting on other boards.

Q:Is the scenario been tried on TI C5517 EVM ?
A: No, I do not is to experiment


Regards,
Da

HI
The problem that I can't answer you, I answered.

> Also, I am not sure about your last statement “This condition can be confirmed when the DSP of 87MHz, if they were to 174MHz, although the frequency is lowered, occur” could you elaborate ?

84MHz and 174MHz are the operating frequency of the DSP.

The operating frequency of the DSP has a high frequency of occurrence by 84MHz, and the frequency of occurrence is low by 174MHz.

The frequency is confirmed by 84MHz and the frequency of occurrence doesn't change that mostly by the following frequency.

When setting 174MHZ, the frequency of occurrence fell.

Check Operating Frequency
84MHz ... occur per one ~ two hour
74MHz ... occur par one~ two hour
|
174MHz ... occur per one day ...


> any UHPID access that occurs while the write FIFO is full or the read FIFO is empty may result in some number of wait states being inserted by the UHPI. Is this been checked ?


It isn't being checked.

But, the previous access has normally ended, so I can't think Full in FIFO and Empty influence.

Sequence
1. HPI Data access < Success.( not Low HRDY )
2. ... wait
3. Sleep
4. ... wait
5. Wake-up
6. HPIC access
7. HPIA Access < HRDY Low Occurrence. ... per hour




Regards.
Da

Hi,

Could you please answer my below questions.

Just before this issue occurred, what was the previous HPI operation or access performed ? Was any pre-fetch operation been done just prior to HPIA write operation ?

 

Whether all the Electrical data and timing, as per section 5.7.18.1 C5517 datasheet is taken care ?

  

Is there any way you could capture HPIC register content when this issue occurs and prior to this issue?

 

Considering 84 MHz, when exactly the issue happened after idle, is this after few HPI transfers ? or after several transfers. Does this happen randomly or this happen exactly after certain amount of transfers ?

 

You had mentioned about device placed in idle mode, which idle mode was the device placed in?

 

Any additional software for other tasks been run simultaneously ? If so , then have you tried turning off those tasks ?

 

From the snapshot you had shown earlier, (for the failure scenario) when HDS2 is asserted low , HRDY also asserts low, it looks similar to explanation provided along with Fig 16-14 in the TRM and relates to FIFO empty condition. Whereas for the passing scenario in your snapshot the HRDY asserts low after HDS2 asserts and looks normal with respect HPIA access FIFO conditions looked satisfied. This was one of the reason for suspecting FIFO conditions. Rechecking this will help.

 

Regards

Vasanth

Hi, Thank you for support.

> Just before this issue occurred, what was the previous
> HPI operation or access performed ?
> Was any pre-fetch operation been done just prior to
> HPIA write operation ?

They do access to HIPC before HPIA write.

> Whether all the Electrical data and timing, as per
> section 5.7.18.1 C5517 datasheet is taken care ?

There was no problem about the timing.

> Is there any way you could capture HPIC register content
> when this issue occurs and prior to this issue?

They can read to HPIC.

> Considering 84 MHz, when exactly the issue happened after idle,
> is this after few HPI transfers ? or after several transfers.
> Does this happen randomly or this happen exactly after certain
> amount of transfers ?

When frequently not transfering data, a problem occurs.
It isn't being checked about the regularity.

> You had mentioned about device placed in idle mode,
> which idle mode was the device placed in?

This problem occurs after idle mode is released.

> Any additional software for other tasks been run simultaneously ?
> If so, then have you tried turning off those tasks ?

I don't hear that that they're using a RTOS.

> From the snapshot you had shown earlier, (for the failure scenario)
> when HDS2 is asserted low, HRDY also asserts low, it looks similar
> to explanation provided along with Fig 16-14 in the TRM and relates
> to FIFO empty condition.
> Whereas for the passing scenario in your snapshot the HRDY asserts
> low after HDS2 asserts and looks normal with respect HPIA access
> FIFO conditions looked satisfied.
> This was one of the reason for suspecting FIFO conditions.
> Rechecking this will help.

When there are no problems with a destination,
can I think HRDY Low by Fifo is released?
HRDY will be the condition which maintained low in
the confirmed area.

Even if they waited for about 1 second when a problem occurred,
HRDY Low wasn't released.

Additional Information

Occur Problem
Power down set -> Clock gen disable

Not occur Problem
Clock gen disable -> Power down set

Details will make sure, Do you have any recommendations?

Regard
Da

Hi,

Thanks, While I am going through your other information I need the following details from you.

• What is the HPIC register value when the issue occurred and the HPIC register value for the previous HPI transfer.
• Which idle mode was the device placed in ? is it IDLE 2 or IDLE3 ?

I might have additional questions based on the information you provided I will get back later.

Regards

 Vasanth

Hi, Vasanth

> HPIC value

I requested HPIC register value of my customer.
Because event probability of a problem falls when an emulator is connected.
I don't get its value.
Please wait a moment about the value.

> IDLE2 or IDLE3

They using IDLE3.


They found the way to which a problem does not occurs.( more than one week )

There is IDLE3 Procedure in p103 of a TRM. (spruh16b.pdf).
When they run the step3 after step10, the problem no longer occurs.
(When they do by a procedure of a manual, a problem occurs.)

and

Delay of 4 cycles is inserted behind step 9. ( insert 4 NOPs )


It's different from a manual, but are these a right way?


Additional Information
HRDY is Low, will be resolved by HPI Reset.

Regards,
Da

Hi,

Thanks for providing additional information.

With respect to inserting NOPs not sure how this matters & its also been added before Step 9. May be adding additional delay is causing the current transfer to complete successfully ?  Would be interested to know on few more things.

• Follow the idle procedure as mentioned in the TRM (page 103), but add additional delay before executing step 3 and let us know the outcome.
• Which peripherals are being disabled as part of Step 3, can you share the content of PCGCR1 & 2 registers.

Will wait for your further inputs on the above and HPIC register.

Regards

 Vasanth

Hi, Vasanth

When the problem occurs, before entering the IDLE, the data transfer has been completed.

Before it's IDLE, HRDY is High.

PCGCR1 & 2 registers

PCGCR1(1C02h)　=　0x7FDF
/* SYSCLKDIS 0--- ---- ---- ---- 0x0000 System -> active */
/* I2S2CG -1-- ---- ---- ---- 0x4000 I2S2 -> disabled */
/* TMR2CG --1- ---- ---- ---- 0x0000 TMR2 -> disabled */
/* TMR1CG ---1 ---- ---- ---- 0x0000 TMR1 -> disabled */
/* EMIFCG ---- 1--- ---- ---- 0x0800 EMIF -> disabled */
/* TMR0CG ---- -1-- ---- ---- 0x0000 TMR0 -> disabled */
/* McSPICG ---- --1- ---- ---- 0x0000 McSPI -> disabled */
/* I2S0CG ---- ---1 ---- ---- 0x0100 I2S0 -> disabled */
/* MMCSD1CG ---- ---- 1--- ---- 0x0080 MMCSD1 -> disabled */
/* I2CCG ---- ---- -1-- ---- 0x0040 I2C -> disabled */
/* McBSPCG ---- ---- --0- ---- 0x0000 McBSP -> active */
/* MMCSD0CG ---- ---- ---1 ---- 0x0010 MMCSD0 -> disabled */
/* DMA0CG ---- ---- ---- 1--- 0x0000 DMA0 -> disabled */
/* UARTCG ---- ---- ---- -1-- 0x0004 UART -> disabled */
/* SPICG ---- ---- ---- --1- 0x0002 SPI -> disabled */
/* I2S3CG ---- ---- ---- ---1 0x0001 I2S3 -> disabled */

PCGCR2(1C03h)　=　0x00FE
/* Reserved 0000 0000 ---- 0x0000 Reserved */
/* McSPI,SPIREFCG ---- ---- 1--- ---- 0x0000 McSPI,SPIREG -> disabled */
/* ANAREGCG ---- ---- -1-- ---- 0x0000 ANAREG -> disabled */
/* DMA3CG ---- ---- --1- ---- 0x0000 DMA3 -> disabled */
/* DMA2CG ---- ---- ---1 ---- 0x0000 DMA2 -> disabled */
/* DMA1CG ---- ---- ---- 1--- 0x0000 DMA1 -> disabled */
/* USBCG ---- ---- ---- -1-- 0x0004 USB -> disabled */
/* SARCG ---- ---- ---- --1- 0x0000 SAR -> disabled */
/* UHPICG ---- ---- ---- ---0 0x0000 UHPI -> active */

It's about HPIC, but I want you to wait a moment. A problem doesn't happen.

Regards,

Da

Hi

You have the parameters of a request not been acquired yet.
Time has passed, so I'd like to settle a problem rather early, so your, please cooperate.

> Follow the idle procedure as mentioned in the TRM (page 103), but add
> additional delay before executing step 3 and let us know the outcome.

How much should be waiting for?
The current delay of about 850ns.


> There is IDLE3 Procedure in p103 of a TRM. (spruh16b.pdf).
> When they run the step3 after step10, the problem no longer occurs.
> (When they do by a procedure of a manual, a problem occurs.)

If they went the replacement of this order, or there is no problem?


Regard,
Da

Hi,

Thanks for providing additional details.

The delay (850 ns) you mentioned looks to be good enough.

 

With respect to running Step3 after step10, below is my suggestion.

 

As part of step3, disable respective peripheral clocks and continue with the other steps as per technical reference manual. But after step10, disable SYSCLKDIS (PCGCR1 – bit 15 ) and then execute Idle instruction.

You could also refer to idle3 example provided as part of CSL3.06, which is downloadable from the link http://www.ti.com/tool/SPRC133 - C55XCSL-LOWPOWER -  idle examples are included in "power" directory/folder.

 

Hope this helps.

 

Regards

Vasanth

Thank you very much for your advice.

I'm sorry.

It was inaccurate about order of ILDE3 which was being told.

TRM
1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11

Costumer's Code order( and not used USB )
1, 2, 3, 5, 6, 7, 8, 9, 10, 4, 11


If you run in the following order problem (HRDY is Low) does not occur.

"10.Power down the PLL by..." -> "4.Disable the clock generator domain"

Run in this order
It does not occur problem with the device specific?



Regards,
Da