Quantcast

How to debug hardware problem?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

How to debug hardware problem?

glamprecht
This post was updated on .
I've designed some of my own expander boards and manufactured 6 of them. I have taken the Chestnut43 as basis. I also have a Chestnut43.

On the Overo Fire after a second of power up, the middle led gives a flash and then about 2 seconds later the blue LED starts flashing. This indicates that it is booting up. If the reset is held in or it does not boot up the middle LED just stays on.

If I plug in the Overo Fire on the Chestnut43 it boots up.

If I plug in the Overo Fire onto any of my 6 boards, the middle LED just stays on. I presume it does not boot up. I have only populated the 3.3V power supply and nothing else. Am I correct in saying that if only power is applied to the 4 3.3V lines and the 4 GND lines it should start up? All the other signals can be floating?

Back to the Chestnut43 all works.

To eliminate my Power Supply which I think is perfect, I have desoldered my 3.3V regulator and cross wired the Chestnut 3.3V to my board with 1.5" 1.5mm square cable. I have some 10uF low esr caps close to the 70 pin connectors. Still does not work.

I have double checked that the pins where I have 3.3v and GND connected is 100% the same as the eagle PCB layout files for the Chestnut43. I dont have the wrong pins. I do not have AGND connected to anything.

I have tried adding a reset switch without any luck.

Either my presumption that it should work with stock firmware if only 3.3V is applied is incorrect, or there is something not shown on the Chestnut43 schematics or there is something wrong with my 70pin connectors.

In any case is there any way that I can use a multimeter/oscilloscope or logic analyser connected to parts/pads on the OVERO itself to see if it is in Reset state or not. Whether it is power-good or not? I have no problem soldering wire wrap wire on 0402 or even smaller scale.

Hope someone can help me. I am really stuck here.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to debug hardware problem?

ashcharles
Hi,

If the console/RX line is floating, the OMAP boot ROM may think
something is trying to communicate. This line should be high
impedance.

-Ash

On Sun, Mar 25, 2012 at 12:03 PM, glamprecht <[hidden email]> wrote:

> I've designed some of my own expander boards and manufactured 6 of them. I
> have taken the Chestnut43 as basis. I also have a Chestnut43.
>
> On the Overo Fire after a second of power up, the middle led gives a flash
> and then about 2 seconds later the blue LED starts flashing. This indicates
> that it is booting up. If the reset is held in or it does not boot up the
> middle LED just stays on.
>
> If I plug in the Overo Fire on the Chestnut43 it boots up.
>
> If I plug in the Overo Fire onto any of my 6 boards, the middle LED just
> stays on. I presume it does not boot up. I have only populated the 3.3V
> power supply and nothing else. Am I correct in saying that if only power is
> applied to the 4 3.3V lines and the 4 GND lines it should start up? All the
> other signals can be floating?
>
> Back to the Chestnut43 all works.
>
> To eliminate my Power Supply which I think is perfect, I have desoldered my
> 3.3V regulator and cross wired the Chestnut 3.3V to my board with 1.5" 1.5mm
> square cable. I have some 10uF low esr caps close to the 70 pin connectors.
> Still does not work.
>
> I have tried adding a reset switch without any luck.
>
> Either my presumption that it should work with stock firmware if only 3.3V
> is applied is incorrect, or there is something not shown on the Chestnut43
> schematics or there is something wrong with my 70pin connectors.
>
> In any case is there any way that I can use a multimeter/oscilloscope or
> logic analyser connected to parts/pads on the OVERO itself to see if it is
> in Reset state or not. Whether it is power-good or not? I have no problem
> soldering wire wrap wire on 0402 or even smaller scale.
>
> Hope someone can help me. I am really stuck here.
>
> --
> View this message in context: http://gumstix.8.n6.nabble.com/How-to-debug-hardware-problem-tp4654354p4654354.html
> Sent from the Gumstix mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> gumstix-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gumstix-users

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: How to debug hardware problem?

glamprecht

I did pull up RX. Finally after 3 days I found the problem, but still do not understand why it would not boot.

 

I chose the most expensive PCB manufacturer for the 6 prototypes - 4 layer board. They are capable of doing 64 layers. Well so they made a mistake with the photoplotting and shorted the following lines internally to the ground plane.

 

ETH0_CS

EM_D15

EM_D12

ETH0_NCS

 

Gerhard

 

From: Ash Charles-2 [via Gumstix] [mailto:[hidden email]]
Sent: 30 Maart 2012 06:49 PM
To: glamprecht
Subject: Re: How to debug hardware problem?

 

Hi,

If the console/RX line is floating, the OMAP boot ROM may think
something is trying to communicate. This line should be high
impedance.

-Ash

On Sun, Mar 25, 2012 at 12:03 PM, glamprecht <[hidden email]> wrote:


> I've designed some of my own expander boards and manufactured 6 of them. I
> have taken the Chestnut43 as basis. I also have a Chestnut43.
>
> On the Overo Fire after a second of power up, the middle led gives a flash
> and then about 2 seconds later the blue LED starts flashing. This indicates
> that it is booting up. If the reset is held in or it does not boot up the
> middle LED just stays on.
>
> If I plug in the Overo Fire on the Chestnut43 it boots up.
>
> If I plug in the Overo Fire onto any of my 6 boards, the middle LED just
> stays on. I presume it does not boot up. I have only populated the 3.3V
> power supply and nothing else. Am I correct in saying that if only power is
> applied to the 4 3.3V lines and the 4 GND lines it should start up? All the
> other signals can be floating?
>
> Back to the Chestnut43 all works.
>
> To eliminate my Power Supply which I think is perfect, I have desoldered my
> 3.3V regulator and cross wired the Chestnut 3.3V to my board with 1.5" 1.5mm
> square cable. I have some 10uF low esr caps close to the 70 pin connectors.
> Still does not work.
>
> I have tried adding a reset switch without any luck.
>
> Either my presumption that it should work with stock firmware if only 3.3V
> is applied is incorrect, or there is something not shown on the Chestnut43
> schematics or there is something wrong with my 70pin connectors.
>
> In any case is there any way that I can use a multimeter/oscilloscope or
> logic analyser connected to parts/pads on the OVERO itself to see if it is
> in Reset state or not. Whether it is power-good or not? I have no problem
> soldering wire wrap wire on 0402 or even smaller scale.
>
> Hope someone can help me. I am really stuck here.
>
> --
> View this message in context: http://gumstix.8.n6.nabble.com/How-to-debug-hardware-problem-tp4654354p4654354.html
> Sent from the Gumstix mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> gumstix-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gumstix-users

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users


If you reply to this email, your message will be added to the discussion below:

http://gumstix.8.n6.nabble.com/How-to-debug-hardware-problem-tp4654354p4671860.html

To unsubscribe from How to debug hardware problem?, click here.
NAML

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to debug hardware problem?

Dan Nelson

I’ve taken this from the design recommendations for custom expansion boards on the Gumstix site:

 

“4.  Noise on the UART_RX3 line during boot can interrupt the normal booting sequence. Consider adding a pull-up resistor to a SYSEN-gated 1.8V supply on this line.”

 

Can anyone tell me what this means?

 

This isn’t  implemented on the Tobi board, there are no pull-ups.   The Tobi board leaves the UART_RX3 line floating until its gate is enabled by SYSEN.  Is this what’s recommended?  Or do you enable the 1.8 volt supply straight away (and thus the gate) and pull up  UART_RX3 to 1.8 volts?  Which would tend to contradict:

 

“1.  Use the SYSEN line to protect any IO pins to the OMAP CPU. SYSEN is brought high when the Overo is ready to communicate; driving GPIOs before this point can damage the processor.”

 

 

Thanks

 

Dan


------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: How to debug hardware problem?

glamprecht

It is a matter of timing.

 

The SYSEN line goes high before the Gumstix looks for input on UART. At the time when the Gumstix looks for input on the UART, the UART is already pulled up.

 

The SYSTEN line is active high – which makes sense, because it should be low when there is no power. However the OE lines on the voltage converter chips are all active low. This means you need to add a single inverter chip.

 

Gerhard

 

From: Dan Nelson [via Gumstix] [mailto:[hidden email]]
Sent: 04 April 2012 11:37 AM
To: glamprecht
Subject: Re: How to debug hardware problem?

 

I’ve taken this from the design recommendations for custom expansion boards on the Gumstix site:

 

“4.  Noise on the UART_RX3 line during boot can interrupt the normal booting sequence. Consider adding a pull-up resistor to a SYSEN-gated 1.8V supply on this line.”

 

Can anyone tell me what this means?

 

This isn’t  implemented on the Tobi board, there are no pull-ups.   The Tobi board leaves the UART_RX3 line floating until its gate is enabled by SYSEN.  Is this what’s recommended?  Or do you enable the 1.8 volt supply straight away (and thus the gate) and pull up  UART_RX3 to 1.8 volts?  Which would tend to contradict:

 

“1.  Use the SYSEN line to protect any IO pins to the OMAP CPU. SYSEN is brought high when the Overo is ready to communicate; driving GPIOs before this point can damage the processor.”

 

 

Thanks

 

Dan


------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users


If you reply to this email, your message will be added to the discussion below:

http://gumstix.8.n6.nabble.com/How-to-debug-hardware-problem-tp4654354p4685932.html

To unsubscribe from How to debug hardware problem?, click here.
NAML

Loading...