Embedded Intel Atom® Processors
Intel Atom® Hardware, Software, Firmware, Graphics
Announcements
This community is designed for sharing of public information. Please do not share Intel or third-party confidential information here.

PMU_SLP_S45_N doesn't de-assert

jamesadupre
Novice
443 Views

I am working on a design using the C3958 processor. The PMU_SLP_S45_N signal never de-asserts even though the voltage sequencing is correct per the EDS to the best of my reckoning (I've looked at it several times with a scope and logic analyzer and am using the CPLD code for the Harcuvar CRB). I see that the SPI_MISO and IO2/3 outputs from the Flash EEPROM toggle so the C3958 is reading information from the Flash EEPROM. I've programmed several BIOS images into the Flash EEPROM including the HVLRCRB.86B.WR.64.2021.17.4.01.1422.HCV16D37.bin and an image I created using the FITc tool, so I would have thought that at least one of these images contained the soft strap information that are required for the C3985 to de-assert the PMU_SLP_S45_N signal. However, presumably the C3958 isn't finding the soft strap information it expects because PMU_SLP_S45_N doesn't de-assert. Is there any other reason why the C3958 is not de-asserting the PMU_SLP_S45_N signal aside from not finding the soft strap information in the Flash contents? I have been struggling for weeks on this issue so any guidance anyone can provide would be greatly appreciated.

 

Thanks,

James

0 Kudos
1 Solution
jamesadupre
Novice
382 Views

Hi Carlos,

 

I found the problem. The issue was that the 25MHz crystal wasn't oscillating due to an assembly defect that was shorting CLK_X1_PAD to CLK_X2_PAD. After I removed this short the SLP_S45_N signal de-asserted as expected. I think it would have been helpful to mention that the 25MHz crystal must be oscillating in order for SLP_S45_N to de-assert in the power-on requirements. Thanks for your help regardless.

 

Regards,
James

View solution in original post

3 Replies
CarlosAM_INTEL
Moderator
432 Views

Hello, @jamesadupre:

Thank you for contacting Intel Embedded Community.

We want to address the following questions based on your previous communication:

Could you please clarify if the affected project has been designed by you or by a third-party company? Could you please inform the part number, the name of the manufacturer, and where to find the information of the affected design? 

Could you please let us know the topside markings of the affected processors? In case that you should provide pictures of them will be helpful.

Could you please list the sources used to develop your affected design, and if it has been verified by Intel?

We are waiting for your answer to these questions.

Best regards,

@CarlosAM_INTEL.

 

jamesadupre
Novice
383 Views

Hi Carlos,

 

I found the problem. The issue was that the 25MHz crystal wasn't oscillating due to an assembly defect that was shorting CLK_X1_PAD to CLK_X2_PAD. After I removed this short the SLP_S45_N signal de-asserted as expected. I think it would have been helpful to mention that the 25MHz crystal must be oscillating in order for SLP_S45_N to de-assert in the power-on requirements. Thanks for your help regardless.

 

Regards,
James

CarlosAM_INTEL
Moderator
374 Views

Hello, @jamesadupre:

Thanks for your answer.

We are glad that you can solve your problem, and thanks for share your solution.

Best regards,

@CarlosAM_INTEL.

Reply