DS90UH947-Q1: 0x13 decode

Hi Corinne,

Thanks for information. I used EVM board and I found my mode_sel had two status, one is 0x8C and the other is 0x8A. May you let me know if possible to have two content if we didn't change the mode_sel resistors?

For 8C=10001100, I don't find # state in the mode_sel0

For 8A =10001010, it's #2 about mode_sel0, is it correct?

In addition, if our PCLK= 50MHz and operate in dual pixel mode. how will ALP show the PCLK value? 50MHz or 100MHz?

Regards,

Roy

Hey Roy,

When you say it had two statuses, were they measured at different times? Is there anything in your software that is overriding the mode selects? 

While the datasheet modes are indexed started at 1 in the table, the register modes are actually decoded starting from index 0. Can you confirm at what points you measured the 2 different statuses? If the values weren't stable your initial reading may not have been accurate. 

The ALP should show a PCLK value of 50MHz.

Best,
Corinne

Hi Corinne,

I re-ask my question as below.

We bought 7pcs EVM board and we selected mode_sel0 = #5. The 0x4F[6] should indicate the dual pixel mode, but when we read 0x4F[6], we found there was still showing single pixel mode. Can you help use your side EVM to check if issue can be duplicated?

We only powered on the 947 board and no connection to 948 and 947 oLDI input.

Regards,

Roy

Hey Roy,

Can you confirm which value you are reading from 0x4F[6]? For OLDI mode you should see 0, not 1 like the strap mode for mode_sel0 = #5 would suggest. I have included the register table and the note that confirms this.

Best,
Corinne

Hi Corinne,

As I said, there is conflict between mode_sel setting and 0x4F[6] bit. 0x4F[6] =  '1' when I set mode_sel0 = #5 .

I need to use ALP to modify the 0x4F[6] by myself and let panel normal operated. Can you use your side EVM to check whether can duplicate the issue? 

Regards,

Roy

Hi Corinne,

It can fix. We tried to add 10k+10uF on PDB pin, but useless. Do we fix the issue in EVM?

In addition, can we use 947 as single oLDI Mode and as 948 Dual oLDI + SPWG Mode?

Regards,

Roy

Hey Roy,

Roy Chou1 said:

It can fix. We tried to add 10k+10uF on PDB pin, but useless. Do we fix the issue in EVM?

Just to confirm did the PDB solution work? Additionally, why were you looking for a way to fix it on the EVM with hardware? 

Roy Chou1 said:

In addition, can we use 947 as single oLDI Mode and as 948 Dual oLDI + SPWG Mode?

Can you please elaborate on what your use case is for this question?

Best,
Corinne

Hi Corinne,

I can fix the issue by using below action. But if the issue was related to PDB delay. I think it can be fixed by adding RC circuit on PDB pin, but useless. We want to fix the issue because in real case, we can manually do the above action.

Corinne Meyers said:

can you try hold and releasing the PDB after you have strapped the values and powered on the device to see if that fixes the issue?

For 2nd question, I want to confirm that if we can use different oLDI format on 947 input side and 948 output side.

Regards,

Roy

Hey Roy,

This is an EVM specific issue that would not appear in production, so there shouldn't be any concern about the PDB delay in a real case.

Roy Chou1 said:

For 2nd question, I want to confirm that if we can use different oLDI format on 947 input side and 948 output side.

Can you please provide a block diagram or schematic demonstrating your setup?

Best,
Corinne

Hi Corinne,

I want to follow up below need. May you help check if there is any method that we dont need to manually hold and release the PDB when system power up? 

Corinne Meyers said:

This is an EVM specific issue that would not appear in production, so there shouldn't be any concern about the PDB delay in a real case.

Regards,

Roy

Hi Logan,

We tried to add more cap on PDB pin cap, but useless. This is EVM's issue. May you help try it in your side?

Our target is that fix the issue in hardware circuit instead of manually action. Thank you.

Regards,

Roy

Hi Roy, 

Trying to get caught up on this issue. Can you summarize the issue you are seeing here with PDB and this mode strap? 

Regards, 

Logan

Hi Logan,

The background is that my customer bought 5pcs 947EVM and we found that the issue in mode_sel. The mode_sel can't be modified by using resistor setting.

Roy Chou1 said:

We bought 7pcs EVM board and we selected mode_sel0 = #5. The 0x4F[6] should indicate the dual pixel mode, but when we read 0x4F[6], we found there was still showing single pixel mode. Can you help use your side EVM to check if issue can be duplicated?

We only powered on the 947 board and no connection to 948 and 947 oLDI input.

And Corinne can duplicate the issue from her side.

Corinne Meyers said:

We tested this in the lab for you and were able to replicate the issue. We think it may be a startup sequence issue for the EVM specifically, can you try hold and releasing the PDB after you have strapped the values and powered on the device to see if that fixes the issue?

She suggest us below action and it can be fixed. 

Corinne Meyers said:

can you try hold and releasing the PDB after you have strapped the values and powered on the device to see if that fixes the issue?

And I tried to add one more 10uF cap on PDB pin, but useless. I would like to if there is any method can fix the issue instead of using manual action. Thank you.

Regards,

Roy

Hi Roy, 

Thanks for the background. 

Do you happen to have a power sequence waveform with the added capacitance? 

If you haven't already, can you sanity check the voltage of the mode_sel so we can also rule out incorrect incorrect voltage/resistor values, etc?

Even with the added capacitance, if you hold the PDB button while powering up the EVM; then release, it will always go into the correct mode? 

Regards, 

Logan

Hi Logan,

For customer side, yes, it can go into the correct mode when did below action.

Logan Cummins said:

you hold the PDB button while powering up the EVM; then release, it will always go into the correct mode? 

For measurement, may you help use your side EVM to do the test? Customer doesn't tend to do the test because they think EVM should be ok and they also buy them from TI store. And I don't have EVM either.

Regards,

Roy

Hi Roy, 

Yes, will try to reproduce in next 1-2 days. I'll confirm with you soon. 

Did customer try a hard reset instead of PDB?

Regards, 

Logan

Hi Roy, 

During customers testing - were they inputting OLDI data into device when coming out of PDB reset? 

We've confirmed from our side that issuing a longer PDB delay on power-up would correctly strap the device. 

Regards, 

Logan

Hi Logan,

How did you do the action? 

Logan Cummins said:

a longer PDB delay

Regards,

Roy

Hi Roy,
In that case we just held PDB low while initially powering. up, then released after delay.

Regards,

Logan

Hi Logan,

Yes, we also could fix the issue by using the step.

But customer are check if there is method can fix the issue without using manually action.

Regards,

Roy

Hi Roy,

Can you verify if customer is inputting OLDI data before release of PDB as per the recommended startup sequence?

I will also have the team try to issue a hard reset to see if this can switch modes, we forgot to try this in initial testing. 

Regards,

Logan

Hi Logan,

Yes, they met the sequence. Do you have any update in your side?

Logan Cummins said:

Can you verify if customer is inputting OLDI data before release of PDB as per the recommended startup sequence?

Regards,

Roy