Hardware bug report V4, cosmetic, easy to fix

[x3mfly]

i have expirienced very unpredictive trouble with software power off, which is implemented in open9x code

1st) fixed code to prevent exit from main() code, because physical switch off happens not same time as cpu restarted on return from main() function

2nd) seems hardware itself has wrong levels on Q9 base, not sure qhy and not sure how to catch :-)

fixe done as: C63 replaced with 10K resistor, now works fine, i know C63 need for bounce cancelling on jack present signal, another one way put extra 10K resistor over C63, but i have not tried...

another one idea about C32 fried in another branch here, i think it just got out of working range, farnell docs said 10V rated, 16V fused, it maybe just bad capacitor + overheat when soldering it reduces working range too + fresh battery + random thing happens = fried, i have replaced it with ceramic 10uF, just to be sure it not happens with my PCB :-)

Max.

[Cam]

>i have expirienced very unpredictive trouble with software power off,
>which is implemented in open9x code

Can you explain this unpredictive behavour ?

--
Cam

[x3mfly]

Yes i can,

when soft power hold happens in random cases it hangs with power on. it is enough to touch transistor legs with scope probe to reset state, sometime finger enough to switch off complete.

i have tried complete software fix like as for(;;){power_on();delay();power_off()} at end of main() function, it works too! but looks stupid! i have choosen to replace cap with resistor, it seems works too. not sure how to catch - it is very inpredictive...

среда, 16 мая 2012 г., 23:06:00 UTC+4 пользователь th9xer написал:

[Michal Hlavinka]

On Wed, 16 May 2012 04:55:11 -0700 (PDT), x3mfly
<maxim....@gmail.com> wrote:
> i have expirienced very unpredictive trouble with software power off, which
> is implemented in open9x code
>
> 1st) fixed code to prevent exit from main() code, because physical switch
> off happens not same time as cpu restarted on return from main() function
> 2nd) seems hardware itself has wrong levels on Q9 base, not sure qhy and
> not sure how to catch :-)

I've seen that too, but I did not have enough time to debug it...

> another one idea about C32 fried in another branch here, i think it just
> got out of working range, farnell docs said 10V rated, 16V fused, it maybe
> just bad capacitor + overheat when soldering it reduces working range too +
> fresh battery + random thing happens = fried, i have replaced it with
> ceramic 10uF, just to be sure it not happens with my PCB :-)

Battery was not fresh (there was low battery warning on turn on). I've
ordered
20 V version of that capacitor (the highest voltage for same
capacity and same dimensions).

[x3mfly]

среда, 16 мая 2012 г., 23:36:40 UTC+4 пользователь mihlit написал:

On Wed, 16 May 2012 04:55:11 -0700 (PDT), x3mfly

and this is strange :-( another one version but it is even stranger - big motor you have used causes spikes on this capacitor which even stranger than thermal damage

but maybe it is combination of different things and we not knows which ones. Maybe fresh battery killed damaged with thermal shock capacitor then spike from moter and it shortened.... dont know really

[Michal Hlavinka]

>> > another one idea about C32 fried in another branch here, i think it just
>> > got out of working range, farnell docs said 10V rated, 16V fused, it
>> maybe
>> > just bad capacitor + overheat when soldering it reduces working range
>> too +
>> > fresh battery + random thing happens = fried, i have replaced it with
>> > ceramic 10uF, just to be sure it not happens with my PCB :-)
>>
>> Battery was not fresh (there was low battery warning on turn on). I've
>> ordered
>> 20 V version of that capacitor (the highest voltage for same
>> capacity and same dimensions).
>>
>> and this is strange :-( another one version but it is even stranger - big
> motor you have used causes spikes on this capacitor which even stranger
> than thermal damage
> but maybe it is combination of different things and we not knows which
> ones. Maybe fresh battery killed damaged with thermal shock capacitor then
> spike from moter and it shortened.... dont know really

It'd be my first guess, that it was some voltage spike caused by the
motor,
but it's input capacitor of that regulator, not the output one

[Cam]

Hmmm, it sounds like a subtle component difference I think. I have never
had it happen yet. Did you build from PCB ? Did you change any
components, anything else to mention ?

I wonder if changing R111 to a lower value might help C63 discharge
quicker at power off. It would be interesting to try as I don't think
anyone else has reported this so far.

I do think I high value resistor in parallel with C63 might be a good
idea.

Cam.

>Yes i can,
>
>when soft power hold happens in random cases it hangs with power on. it
>is enough to touch transistor legs with scope probe to reset state,
>sometime finger enough to switch off complete.
>
>i have tried complete software fix like as
>for(;;){power_on();delay();power_off()} at end of main() function, it
>works too! but looks stupid! i have choosen to replace cap with
>resistor, it seems works too. not sure how to catch - it is very in
>predictive...
>
>
>

>?????, 16 ??? 2012 ?., 23:06:00 UTC+4 ???????????? th9xer ???????:

[x3mfly]

in fact it not discharges at all! but i'm very unsure, because if i touch transistor base with scope or multimeter probe it powering off normaly! so i cant catch it! but C->R replacement seems fixed this behaviour, i will try to install R in parallel to C too, but not right now, time to sleep :-)

среда, 16 мая 2012 г., 23:47:34 UTC+4 пользователь th9xer написал:

[Cam]

This is very strange, the CPU is holding Hold_PWR_ON low and yet Q9
doesn't switch off !

I wonder if PL7 is configured correctly. Or if the internal pull up on
Jack_presence_TTL (PL6) has anything to do with it.

Worse is I can't really test as my set is yet to do it !!! I'll check
the code.

Cam.

>in fact it not discharges at all! but i'm very unsure, because if i
>touch transistor base with scope or multimeter probe it powering off
>normaly! so i cant catch it! but C->R replacement seems fixed this
>behaviour, i will try to install R in parallel to C too, but not right
>now, time to sleep :-)
>

>?????, 16 ??? 2012 ?., 23:47:34 UTC+4 ???????????? th9xer ???????:

[Cam]

Code looks ok, maybe try turning the pullup on PL6 off. So in
board_gruvin.cpp initial setup becomes:

DDRL = 0x80; PORTL = 0xbf;

And turn off becomes:

PORTL = 0x3f;

Can you also verify if you have time that PL7 is low while the main
power switch is off and the Tx is still on.

Maybe it's a brownout type issue, a fuse check might me in order. Or
change the shutdown code to make the LCD still display something
meaningful so you can see if the CPU is still running.

Just ideas, hard for me to know without seeing the problem :(
--
Cam

[Bryan]

Well, the sun has come around to my part of the world, so I shall delight you all with my own random comments. :-)

The issue with C63, based on what I've read and my own theoretical analysis, I believe will be a case of oscillation, at least briefly which sometimes causes just the right type of crash in the MCU to mess up the port configuration enough -- or perhaps even continual high frequency oscillation.

I believe oscillation could take place at the threshold of Q9's switch-on point. This is not something I would have predicted, but it seems possible, given that we are removing power to the circuit entirely. thus allowing for at least a temporary state of high impedance, where we'd not normal expect it.

In any case, it seems that a 100K resistor placed across C63 will fix the problem. (Value chosen because it is used elsewhere also, rather than adding yet another single instance of a new value resistor.)

Re C32; this one is listed in the BOM as a tantalum 16V. I am not at home right now, so cannot look at a Chinese factory board to verify. But it sounds to me as though the capacitor in question (the one that blew up)  is (or was) not a tantalum 16V rated part? If it was a ceramic part (likely 10V rated) then I would suggest that it had been weakened over time, reducing it operating voltage to the point it finally short-circuited. This is speculation of course, but seems the most likely cause, outside of the TI regulator part going bad.

I'm on my way home now. I'll check C32 on a Chinese board I have and should be checking back in soon afterwards.
 
Bryan

[Maxim Karban]

Pullup resistors are disabled because port out function there....

I have resoldered C63, PCB all in flux now, and strange thing - all
works, maybe flux helps to discharge it? i have soldered new R 10K
value on top of C63 and it works too - will leave it as now...

IMHO: there are no discharge path for C63 defined in hardware, only
CPU related, and CPU when power goes down can do something strange
sometime, some time ago, while no infinite loop at main() end and no
wdt_disable() at end it was restarting continiously, not just hangs
like last night with message shutdown on screen and loops! i have
added infinite loop to sop restarting, disabled watchdog, and it
happens not every time! ~1/10-1/20!

i think i have defined hardware path for C63 discharge and seems it
works - will write here if anything wrong or any changes happens.

Max.

[Bryan]

On 17 May 2012 16:44, Maxim Karban <maxim....@gmail.com> wrote:

Pullup resistors are disabled because port out function there....

I have resoldered C63, PCB all in flux now, and strange thing - all
works, maybe flux helps to discharge it? i have soldered new R 10K
value on top of C63 and it works too - will leave it as now...

IMHO: there are no discharge path for C63 defined in hardware

Agreed. Only CPU, diodes and B/E junction of the transistor. As you say, when the power is off, all bets are off for the CPU output pin. In most cases, the B/E junction would be enough, when.if there's just enough (hysteresis) shift it he junction voltage drop after the transistor shuts off. But this cannot be relied upon. It's very easy to forget that the CPU logic level is no longer there, after the power goes off.

I suppose a 10K is also suitable. Perhaps better than a 100K, in fact. I keep forgetting that we're only working at 5V. Too much "old school" floating in my grey matter.
 

...

i think i have defined hardware path for C63 discharge and seems it
works - will write here if anything wrong or any changes happens.

Yup. We seem all agreed. So I'm going to update the v4.2 schematic to include a 10K bleed resistor.

Bryan.

[Maxim Karban]

Maybe better to exchange that resistor logic to diode logic? shall i
draw schema?

[Maxim Karban]

here is my idea

On Thu, May 17, 2012 at 9:48 AM, Bryan <gru...@gmail.com> wrote:
>
>

[Bryan]

There's nothing to "pull up" the transistor's base with just diodes. So it cannot switch on.

On 17 May 2012 18:02, Maxim Karban <maxim....@gmail.com> wrote:

here is my idea

[Bryan]

Of course, a pull-up resistor could be added. But then, what has been gained?

[Bryan]

Also -- and Cam would have to confirm -- but I'm pretty sure that Hold_PWR_ON has to be able to override Jack_Presence_TTL. So that would involve at least one AND gate.

So, I think we'll stick with what we know works -- at lest for now. Too risky to make changes at this late stage, with another factory run hanging in the balance.

Bryan.

[x3mfly]

No probs, understand

and why need overriding of Jack presence?

четверг, 17 мая 2012 г., 12:08:48 UTC+4 пользователь Gruvin написал:

[Bryan]

On 17 May 2012 20:13, x3mfly <maxim....@gmail.com> wrote:

No probs, understand

and why need overriding of Jack presence?

Honestly, I cannot remember the details. I just recall that Cam spent considerable time testing the circuit design to finally arrive at this. The key challenge was actually to ensure it could be done without having to make any changes off of the main board. I have a feeling that the resistors and/or 'override' that I can't quite recall was something to do with that.

Cam?

--
Bryan.

[Bryan]

I have now added R118 (10K) across C63 in both the v4.2 schematic and PCB layout.

In a semi-related note, the Chinese factory is now actively engaged in working out a price for the upcoming v4.2 batch. I've just answered a couple of questions from them. (Last time I had to answer many questions. I'm getting better at preparing the files and data they require. :-D)

Bryan.

[Bryan]

On 17 May 2012 14:47, Bryan <gru...@gmail.com> wrote:

...

I'm on my way home now. I'll check C32 on a Chinese board I have and should be checking back in soon afterwards.

...

I can confirm that the factory made (standard green) PC boards do indeed use a 16V tantalum capacitor for C32.

Bryan.
 

[Cam]

I think the clevit was Jack_Presence_TTL has to only be influenced by
Jack_Presence and not Hold_PWR_ON. Max's schematic would meet this
requirement (provided he is intending to leave the circuitry between
Jack_Presence_TTL and Jack_Presence the same) but as Bryan mentioned it
doesn't really gain us anything.
That aside I would definitely want to try a change like this before
changing the production run. So I am in agreement with just adding a
resistor.

All good with me.

Cam.