AM3352: UART baud rate changes unintentionally

Hi experts,

This is an additional question and information. We have found similar issues in the following threads
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/503313/peripheral-pll-issue-with-am335x?ReplyFilter=Answers&ReplySortBy=Answers&ReplySortOrder=Descending

I understand that the cause of the problem has not been determined, but I suspect a hardware factor. However, let me confirm some points that are unclear.

Q3: What causes the two registers "interrupy status for usb dpll recaliberation" to change? When does the target bit operate and what does it mean?
The USB function is not in use and has been deactivated. In the thread above, "DPLL_PER_RECAL_ST (Bit 15)" was discussed but not explained including TRM. It would be appreciated if you could let us know if there is a possibility that this issue is related to this problem.

Q4:There are 4 registers that seem to be related to OPP. Could you please tell me what the bits (0-23) in those registers represent?
I could not find any information in the documentation or on E2E, but it would be helpful if you could tell me if they might be related to this issue.

Best regards,
O.H

Hi experts,

Sorry for rush you. The customer is looking for answers, so it would be helpful if you could tell us about your current situation. If information is missing, please let us know.

Best regards,
O.H

Hi experts,

Additional investigation by the customer confirmed that only the PerPLL clock was changing at the output of CLKOUT2.
The other L3 and DDR clocks were unchanged. Also, the "interrupt status for usb dpll recaliberation" bit in the PRM_IRQSTATUS_M3 and PRM_IRQSTATUS_MPU registers is set to "1" was set after a clock error.

Could you please tell me about Q3 as it seems to be affected by the "interrupt status for usb dpll recaliberation".

I would appreciate it if you could answer Q2 and Q4 if they are relevant to this issue.

Best regards,
O.H

Hi,

Sorry for rush you. Is there any update? Our customer needs answers to move on to the actual design, so it would be helpful if you could tell us the status.

Please let us know if there is any information missing or unclear.

Best regards,
O.H

Hi O.H.

I apologize for the late response. I was OoO for nearly two weeks and am catching up still.

I agree with peaves on the debug thread you referenced, that the problem statement (in both threads) points to a possible HW issue, likely involving the oscillator circuit, which could reasonably be creating asynchronous timing issues, i.e. the UART baud rate suddenly changing. 

Are you able to remove the 25MHz crystal on the board and insert a waveform generator? Per the debug thread:

"Did you ever try Paul's suggestion of removing your 25 MHz crystal and feeding a 1.8V 25 MHz square wave? [If the issue goes away] That would help us understand if the issue pertains to your clocking."

Regards,

Colin

Hi Colin,

Thank you for your reply.

Colin Callaghan said:

Are you able to remove the 25MHz crystal on the board and insert a waveform generator? Per the debug thread:

"Did you ever try Paul's suggestion of removing your 25 MHz crystal and feeding a 1.8V 25 MHz square wave? [If the issue goes away] That would help us understand if the issue pertains to your clocking."

We have asked the customer to verify the above and confirm the errata (Advisory 1.0.30 ) and will contact you when we know the result.

O.H said:

Additional investigation by the customer confirmed that only the PerPLL clock was changing at the output of CLKOUT2.
The other L3 and DDR clocks were unchanged. Also, the "interrupt status for usb dpll recaliberation" bit in the PRM_IRQSTATUS_M3 and PRM_IRQSTATUS_MPU registers is set to "1" was set after a clock error.

Could you please tell me about Q3 as it seems to be affected by the "interrupt status for usb dpll recaliberation".

O.H said:

Q3: What causes the two registers "interrupy status for usb dpll recaliberation" to change? When does the target bit operate and what does it mean?
The USB function is not in use and has been deactivated. In the thread above, "DPLL_PER_RECAL_ST (Bit 15)" was discussed but not explained including TRM. It would be appreciated if you could let us know if there is a possibility that this issue is related to this problem.

Could you please give us a priority answer to the above question?
The customer is requesting the above information in order to investigate the current issue and understand the situation.

Best regards,
O.H

Hi Colin

The customer replaced X1 with a function generator, and simulated frequency and amplitude fluctuations were input to check the operation. The results and connection diagram are shown below.

(1) Frequency fluctuation

When the frequency dropped nearly 7[MHz] from the operating frequency, the bit(dpll_per_recal_st) in the register below changed to ENABLE, the same as in the case of an error when a crystal is used. However, the frequency fluctuation on the product board was 24.93 to 25.09[MHz] and never fluctuated by 7[MHz]. (24-hour continuous measurement operation variation). Also, during the frequency drop, the internal Per PLL clock was in a fixed state and did not change when the frequency was changed. In this state, data reception from the PC was sometimes not accepted.

[XTALIN frequency measurement waveform of the board]

(2) Amplitude fluctuation

When the amplitude of the frequency dropped from 1.8[V] to nearly 1.2[V], the bit(dpll_per_recal_st, dpll_ddr_recal_st) in the following register changed to ENABLE. However, since the "dpll_ddr_recal_st" bit, which is not confirmed to be abnormal on the board when the crystal unit is used, also changes, we believe that this is different from the abnormality that is currently occurring. After the abnormality occurred, Per and DDR of the internal clock did not change even when the voltage was set back to 1.8[V], and they remained fixed.

Could you please give me your opinion on Q3 and the cause of this problem, including the above results? Please point out if you have any comments on the test method.

Best regards,
O.H

Hi Colin,

Sorry for rush you. The customer is planning to mass produce the product in about a month and a half, so the problem needs to be resolved as soon as possible.

Could you please respond to the above questions by 4/15?

As for additional information, we have not been able to confirm the swap test because we do not have any boards that are not experiencing the problem. Also, there is no temperature dependence.

Best regards,
O.H

Hi O.H.,

I appreciate your friendly reminder. I have scheduled time with an expert on this device to review this tomorrow. I will follow up after the meeting.

Regards,

Colin

Hi O.H.,

A few points:

• While I do not have a definitive answer for you about the meanings of the dpll_usb bits that you were asking in Q3, I agree there is something suspicious with the USB PLL
  • 
  • VDDA1P8V_USB0 supplies the power to the PLL that is sourced for all peripherals. Seeing this bit toggle could relate to the UART baud changes that are observed.
  • Are you able to measure this rail and see less than 50mV pk-pk of noise?
  • 
• O.H said:

  We have asked the customer to verify the above and confirm the errata (Advisory 1.0.30 ) and will contact you when we know the result.
• can you please confirm this? This was the first thing the expert identified as a possible major issue. Even for the experiment with the waveform generator, please confirm that the GND used is PCB digital ground, and not GND_OSC
• Otherwise we are debugging system level noise that needs to be root caused by the customer design engineers, which could be introduced from PCB layout and/or environmental issues.

Regards,

Colin

Hi Colin,

Thank you for your answer. I understood.

Colin Callaghan said:

• Are you able to measure this rail and see less than 50mV pk-pk of noise?
• 

Colin Callaghan said:

can you please confirm this? This was the first thing the expert identified as a possible major issue. Even for the experiment with the waveform generator, please confirm that the GND used is PCB digital ground, and not GND_OSC

We will confirm the above two points with the customer again.

[Postscript]

The VDDA1P8V_USB0 operates with a fluctuation range of 1.792 to 1.803[V], and no noise was observed. In addition, no abnormalities were observed when the voltage was intentionally varied between 1.89[V] and 1.68[V] (in the range of 50 mVp-p or higher) during operation.

In the excerpt, "GND_OSC" and "GND" have different names, but both are connected to the digital ground (VSS) of the PCB.

Best regards,
O.H

Hi Colin,

Sorry for rush you. The customer is looking for answers, so it would be helpful if you could tell us about your current situation. If information is missing, please let us know.

Best regards,
O.H

Hi O.H.,

Noise may be coupling into the cable that connects the signal generator to the customer board. 

TI recommends they remove the crystal components connected to our oscillator pins, dead-bug a 1.8V LVCMOS oscillator on the PCB, connect the 1.8V LVCMOS oscillator output to our oscillator input, and connect the 1.8V LVCMOS oscillator power pins to a nearby 1.8V power source, using very short wires that are tightly coupled to ground for all of these connections (no large loop area in these connections since large loops can pick-up noise).

Nothing else is apparent from the TI perspective. This is a mature device that does not have any history of changing clock behavior, unless there is a source of significant noise on the board that is impacting our SoC. If this doesn’t help the customer may need to look for ground potential differences between their board and any connected devices. 

Regards,

Colin

Hi Colin,

Thank you for your reply. Basically, I understood that it is either external factors such as noise or hardware factors such as circuits, wiring, and components.

Since the AM3352 crystal is mentioned as a problem, could you please confirm whether or not the problem is on the wiring of the excerpt of the pattern around the crystal in the board? We will send the diagram via private chat according to the customer's intention.

I am sorry, but could you also answer the following questions that may be related to this issue? If it is difficult to answer, it would be helpful if you could tell us why.

1. Is there a case where the output of the PER_CLKOUT_M2 clock changes due to settings other than the PerPLL register?
2. Could you please tell me what the bits (0-23) in these registers represent?
   There are the following four registers that may be related to OPP. vdd_mpu_opp_050, vdd_mpu_opp_100, vdd_mpu_opp_120, vdd_mpu_opp_turbo. 
   I could not find this information in the documentation or in E2E, but if there is a possibility that it is related to this issue, I would appreciate it if you could let me know.
   
   

3. Is it expected behavior that the PER_CLKOUTTM2 output would maintain its abnormal state even when the crystal returns to normal?
   I understand that the AM3352 does not have an internal oscillation circuit and that the source of the internal clock is caused by an external crystal. The crystal at the time this anomaly occurred was 25MHz, but the output of PER_CLKOUTTM2 changed from 192MHz to 255MHz. We also checked the PER register settings and found no change before and after the anomaly. Assuming that the problem was caused by a momentary noise on the crystal, we thought that the PER_CLKOUTTM2 output would return to 192MHz when the external crystal returned to normal, but it was fixed at 255MHz.
   
   [5/10 Postscript]
   Sorry, but the customer is very pressed for time and would appreciate an answer by 5/12 regarding the layout.

4. Could you be more specific about the following answer?
   Since there is a change in the following registers(PRM_IRQSTATUS_M3, PRM_IRQSTATUS_MPU) after the anomaly occurred, we require an explanation of the register and the associated bits in order to put the situation in perspective. In your previous response, you said you did not have a clear answer, but if it is difficult to answer, it would be helpful if you could tell us why.
   

   O.H said:

   Q3: What causes the two registers "interrupy status for usb dpll recaliberation" to change? When does the target bit operate and what does it mean?
   The USB function is not in use and has been deactivated. In the thread above, "DPLL_PER_RECAL_ST (Bit 15)" was discussed but not explained including TRM. It would be appreciated if you could let us know if there is a possibility that this issue is related to this problem.

   Colin Callaghan said:

   While I do not have a definitive answer for you about the meanings of the dpll_usb bits that you were asking in Q3, I agree there is something suspicious with the USB PLL

   Best regards,
   O.H

Hi O.H.,

1 -  I am not aware of another case like this.

2 -  we can follow up about the ntarget details but will have to ask for more support. I do not believe this relates to the issue.

3 - There is no expected behavior once the crystal anomaly takes place. The SoC is then in an undefined state where we have not tested. 

4 - The exact reason for the change of baud rate and the PLL status bits is uncertain, since the SoC is in an undefined state after the noise is injected from the crystal oscillator circuitry. Ultimately this is the root of the problem that the customer needs to investigate and root cause. 

AM335 is one of the most mature and tested devices in the Processors Catalog. We do not have a history of debugging this issue, except for applications where there is too much noise injected into the SoC from external sources.

Regards,

Colin

Hi Tony Tang,

Thank you for the information.

I haven't been able to confirm the final solution on your side, but I think they were able to improve it by reviewing the PCB layout and using the advice you gave.

I will close this case with the above thread as the answer.

Best regards,
O.H