Следственный эксперимент: sim300z + подпидка без VDD + VDD_EXT Опции

[groovy]

План действий:

Sim300_EVB_V2.02

К разъему J1, ноги DTR и GND подаю потенциал 3в.
На всяких ногах типа RX, DBG_RX и прочих работающих на вход - появляется потенциал порядка 2в

И самый ужас, на VDD_EXT висящем в воздухе - тоже 2в.

Как же прикажете использовать VDD_EXT для мониторинга состояния модуля и отключения подпитки по входам если при наличии этой самой подпидки сам VDD_EXT как надо не работает???

Изначально я повесил N-канальный полевичек на VDD_EXT, который при наличии потенциала тянет к земле ~OE буферной микросхемы между МК и сим300. Но получается что он элементарно не срабатывает т.к. RX МК подтянут внутри к 3в и прет подпитка.

Если начинать тушить RX и прочее, то спасибо конечно, тут и буферной микросхемы не надо, хотелось сделать надежное решение чтоб при любом глюке софта сработало и вот такой облом.

Подскажите как быть?

Спасибо.

[CADiLO]

Уже неоднократно писалося, что модуль не терпит фантомного питания - то есть до включения модуля ножкой POWERKEY на цифровых входах не должно быть никаких уровней.
Как Вы это обеспечите - уже второй вопрос....
От диодно-резистивной развязки, до буфера с "Z" управляемым STATUS или буфера с ОК и подтяжкой к Vext...

[groovy]

Ну вот скажем есть у меня устройство, включился модем, все работает, и тут модем выключился сам, ну скажем батарея подсела, через RX в него продолжает идти питание, на выходе vdd_ext от этого идет 2в, как понять что модуль в отключке??? только потому что нет ответа на АТ команды? криво...

[CADiLO]

1. если правильно сделано согласование то через RX на него ну никак не пойдет питание.
2. а если продолжает идти - читай пунт первый

о том что он выключился узнаем:
a. по сообщению от модуля
b. по пропаданию "status"
c. по пропаданию "Vext" (кроме 300d)

[groovy]

Прикладываю схему.

Микросхема SN74LVC541A
После включения МК и модуля начинает пропускает GSM_RX. Соответственно прекратиться все может только при полном пропадании VDD_EXT, но такого не случается, по причине наличия того же GSM_RX.


Вариант проверки команд от модуля не рассматривается, т.к. если полагаться на софт, то я и так могу перевести выходы и входы в третье состояние и не осложнять себе жизнь.

Про status, несколько раз наблюдал как при подпитке без питания лампочка просто горит. При неустойчивой работе модуля - вариант ненадежный.

Получается что единственный вариант развязки - это диоды... а они занимают очень уж много места.

Эскизы прикрепленных изображений

 

[=F8=]

Как же прикажете использовать VDD_EXT для мониторинга состояния модуля и отключения подпитки по входам если при наличии этой самой подпидки сам VDD_EXT как надо не работает???

Соедините выход VDD_EXT через 10кОм с землей и будет вам счастье.
Если девайс с ошибкой в разводке уже пошел в серию(как это к сожалению произошло у меня ) то можно кратковременно,на 200мс соединить PWRKEY с землей и после этого проверить состояние VDD_EXT , но для вашей схемы это не подходит, только резистор на землю.

Сообщение отредактировал =F8= - Apr 14 2008, 09:38

[groovy]

Соедините выход VDD_EXT через 10кОм с землей и будет вам счастье.
Если девайс с ошибкой в разводке уже пошел в серию(как это к сожалению произошло у меня ) то можно кратковременно,на 200мс соединить PWRKEY с землей и после этого проверить состояние VDD_EXT , но для вашей схемы это не подходит, только резистор на землю.

Резистор действительно помог, даже не пришлось вешать навесу, просто поменял R58.
Хотя все равно не hi-tech это, но хоть какое-то аппаратное решение.

Спасибо.

[CADiLO]

Чем питаем буфер U14 ?

[groovy]

Питанием с МК, 3в

[CADiLO]

Попробуйте запитать от Vext.
На отладочной плате так запитаны преобразователи RS232.

Можно еще на ключик разрешения завести Status
Если взять буфер с неинверсным входом разрешения - ключик можно выбросить.

И еще - если предусматриваете перепрошивку модуля транслируя сигналы насквозь контроллером, то учтите что при перешивке модуля Status не появляется!

[=F8=]

Попробуйте запитать от Vext.
На отладочной плате так запитаны преобразователи RS232.

Можно еще на ключик разрешения завести Status
Если взять буфер с неинверсным входом разрешения - ключик можно выбросить.

И еще - если предусматриваете перепрошивку модуля транслируя сигналы насквозь контроллером, то учтите что при перешивке модуля Status не появляется!

Не самое удачное решение. В этом случае паразитное питание пойдет на U14 и дальше на модуль. Чтобы отсечь паразитное питание на U14 всегда должно быть нормальное напряжение.

[CADiLO]

Согласен - не лучшее, но предложение было из существующей схемы.

Нормальным решением будут два неинвертирующих буфера с ОК (туда и обратно) и подтяжками резисторами на ОК - со стороны модуля к Vext и со стороны проца к его питанию. Например 74LVC07.

[groovy]

Не самое удачное решение. В этом случае паразитное питание пойдет на U14 и дальше на модуль. Чтобы отсечь паразитное питание на U14 всегда должно быть нормальное напряжение.

Не понял, МК и U14 питаются от общего LDO. Куда чего пойдет?

Попробуйте запитать от Vext.
На отладочной плате так запитаны преобразователи RS232.

Можно еще на ключик разрешения завести Status
Если взять буфер с неинверсным входом разрешения - ключик можно выбросить.

И еще - если предусматриваете перепрошивку модуля транслируя сигналы насквозь контроллером, то учтите что при перешивке модуля Status не появляется!

Питать от Vext неправильное решение, U14 - CMOS микросхема, если питать от Vext и сам Vext пропадет - от МК на микросхему U14 все равно будут приходить потенциалы, возможно они даже пройдут по цепи питания U14 и попадут в тот же Vext. Результат вобщем непредсказуем.

Питать от Vext было моей первой идеей, но вот задумался что может быть случай что МК под напряжением, а U14 - нет. Вариант отбросил.

Не понял, МК и U14 питаются от общего LDO. Куда чего пойдет?
Питать от Vext неправильное решение, U14 - CMOS микросхема, если питать от Vext и сам Vext пропадет - от МК на микросхему U14 все равно будут приходить потенциалы, возможно они даже пройдут по цепи питания U14 и попадут в тот же Vext. Результат вобщем непредсказуем.

Питать от Vext было моей первой идеей, но вот задумался что может быть случай что МК под напряжением, а U14 - нет. Вариант отбросил.

Ой, это все уже обсудили, простите, из спорт зала пришел, мутит слегка

[Baser]

Питать от Vext неправильное решение, U14 - CMOS микросхема, если питать от Vext и сам Vext пропадет - от МК на микросхему U14 все равно будут приходить потенциалы, возможно они даже пройдут по цепи питания U14 и попадут в тот же Vext. Результат вобщем непредсказуем.

Питать от Vext было моей первой идеей, но вот задумался что может быть случай что МК под напряжением, а U14 - нет. Вариант отбросил.

Вполне может быть, что это как раз и правильное решение. Серия 74LVC (74LVX у Fairchild) имеет одну особенность: Power down high impedance inputs and outputs. These devices are fully specified for partial-power-down applications using Ioff. The Ioff circuitry disables the outputs, preventing damaging current backflow through the devices when they are powered down.
Ioff = 10 μA max. (Power-Off Leakage Current) @ Vcc=0, Vin or Vout=5.5V

Да и сам Симком рекомендует питать драйвера модуль-->МК от VEXT.

Сам, правда, это пока не проверял (нахожусь на стадии макета, вместо драйверов пока делители )
Так что это просто информация к размышлению...

p.s. А про 10кОм на VEXT это хорошая мысль, хорошо что я ещё коррекцию платы не делал

p.p.s. Кстати, в последнем Hardware Design SIM300_HD_V3.07 симкомовцы уже даже на NETLIGHT диод влепили. Я просто выпал в осадок: неужели даже обратный ток коллектора транзистора может завалить SIM300. Или это они для перестраховки?

[groovy]

Вполне может быть, что это как раз и правильное решение. Серия 74LVC (74LVX у Fairchild) имеет одну особенность: Power down high impedance inputs and outputs. These devices are fully specified for partial-power-down applications using Ioff. The Ioff circuitry disables the outputs, preventing damaging current backflow through the devices when they are powered down.
Ioff = 10 μA max. (Power-Off Leakage Current) @ Vcc=0, Vin or Vout=5.5V

Да и сам Симком рекомендует питать драйвера модуль-->МК от VEXT.

Сам, правда, это пока не проверял (нахожусь на стадии макета, вместо драйверов пока делители )
Так что это просто информация к размышлению...

p.s. А про 10кОм на VEXT это хорошая мысль, хорошо что я ещё коррекцию платы не делал

p.p.s. Кстати, в последнем Hardware Design SIM300_HD_V3.07 симкомовцы уже даже на NETLIGHT диод влепили. Я просто выпал в осадок: неужели даже обратный ток коллектора транзистора может завалить SIM300. Или это они для перестраховки?

Как то я не уделил достаточного внимания даташиту, Ioff действительно присутствует. Надо бы опробовать.

Про диод на status ничего не скажу, видел, много думал, решил что проще поставить полевик.

Запитал U14 от VDD_EXT.
Оба ~OE - постоянно на землю.
Резистор 10К от VDD_EXT к земле - убрал.

Внешне все работает, только при выключенном модуле создается впечатление что выходы U14 не в третьем состоянии. Осцилл выдает по ним что-то вроде земли. Кажется слышал что это тоже плохо.

[=F8=]

Не понял, МК и U14 питаются от общего LDO. Куда чего пойдет?

Это если U14 от VEXT запитать.

Вполне может быть, что это как раз и правильное решение. Серия 74LVC (74LVX у Fairchild) имеет одну особенность: Power down high impedance inputs and outputs. These devices are fully specified for partial-power-down applications using Ioff. The Ioff circuitry disables the outputs, preventing damaging current backflow through the devices when they are powered down.
Ioff = 10 μA max. (Power-Off Leakage Current) @ Vcc=0, Vin or Vout=5.5V

Тут еще вот, что - у кмоповская логика в статике почти ничего не кушает, а чтоб на VEXT был ноль его нагрузить надо.

p.p.s. Кстати, в последнем Hardware Design SIM300_HD_V3.07 симкомовцы уже даже на NETLIGHT диод влепили. Я просто выпал в осадок: неужели даже обратный ток коллектора транзистора может завалить SIM300. Или это они для перестраховки?

Да не такой уж он нежный этот сим300, я его пытался валить, в разумных пределах разумеется(15В на входы не подавал ) бестолку...

Сообщение отредактировал =F8= - Apr 14 2008, 17:51

[groovy]

Еще добавлю что без резистора VDD_EXT падает медленно, 350-400мс примерно, имхо самое то для всяких слетов, с резистором 4.7к фронт хороший.

[Baser]

Запитал U14 от VDD_EXT.
Оба ~OE - постоянно на землю.
Резистор 10К от VDD_EXT к земле - убрал.

Внешне все работает, только при выключенном модуле создается впечатление что выходы U14 не в третьем состоянии. Осцилл выдает по ним что-то вроде земли. Кажется слышал что это тоже плохо.

Вот как раз резистор от VDD_EXT к земле я бы оставил. Может не 10К а больше, но он необходим: кто "землю" обеспечит, если все в высоком импедансе? Вот и =F8= то же самое говорит.
А проверить, есть ли там третье состояние, просто: подключите осцилл и коснитесь щупа пальцем. Если все равно нуль - нет высокоимпеданса, если 50 Гц наводки на весь экран - есть

Да не такой уж он нежный этот сим300, я его пытался валить, в разумных пределах разумеется(15В на входы не подавал ) бестолку...

Читал здесь мнение уже двух людей, что прошивка периодически слетает у конкретных образцов модулей. А у подавляющего большинства не слетает при самом жестком обращении.
Я при отладке все время питание на ходу снимаю (ну нет у разрабатываемого прибора функции выключения, и не будет ) а модуль все еще цел. Правда снимаю питание с платы, а не с одного модуля, а это разные вещи...

[=F8=]

Еще добавлю что без резистора VDD_EXT падает медленно, 350-400мс примерно, имхо самое то для всяких слетов, с резистором 4.7к фронт хороший.

Надо чтоб на питании модуля напряжение медлено падало, чтоб проц успел корректно работу закончить, а на VDD_EXT особого значения не имеет, может даже немного лучше побыстрее. Насколько я понял при отключении модуля выход VDD_EXT переходит в третье состояние и у него немного "подтекает" верхний транзистор и задача нагрузки просто компенсировать ток утечки.

Читал здесь мнение уже двух людей, что прошивка периодически слетает у конкретных образцов модулей. А у подавляющего большинства не слетает при самом жестком обращении.
Я при отладке все время питание на ходу снимаю (ну нет у разрабатываемого прибора функции выключения, и не будет smile.gif ) а модуль все еще цел. Правда снимаю питание с платы, а не с одного модуля, а это разные вещи...

Похоже на то, но на 100% не уверен. Во всяком случае если к нам на повторный ремонт приходит девайс с проблемами с модулем то меняем либо модуль, либо всю плату целиком.

[Baser]

Во всяком случае если к нам на повторный ремонт приходит девайс с проблемами с модулем то меняем либо модуль, либо всю плату целиком.

Если у вас есть статистика по отказам и слетам прошивки SIM300, и если она не секретная ,
то поделитесь, pls!
У меня еще прибор в серию не пошел, статистики нет, а к чему быть готовым, знать хочется.

[=F8=]

Если у вас есть статистика по отказам и слетам прошивки SIM300, и если она не секретная ,
то поделитесь, pls!
У меня еще прибор в серию не пошел, статистики нет, а к чему быть готовым, знать хочется.

Извините статистику дать не могу,это не от меня зависит. Могу только сказать, что для наших задач уровень отказов в целом приемлем. Тут еще есть такая проблема у меня есть ошибка в разводке платы, из-за чего паразитное питание поступало на RXD1(программно я этот бок частично убрал, но всетаки...) так, что не хотелось попусту наговаривать на модуль и валить свои проблемы на него, вот когда в новой версии платы эти бока уберу тогда можно будет что-то говорить с уверенностью.

Сообщение отредактировал =F8= - Apr 15 2008, 11:35

[YAM]

Могу привести нашу статистику. Где-то около 120 девайсов с наглым отрубанием питания в случае неполадок с модулем SIM300C разных версий от 06 до 12 с памятью spansion. Правда перед выключением питания и после включения держу ноги процессора в Z. Перезимовали 2 зимы. полет нормальный. По мере обслуживания просто переписывали firmware на более свежую. Используется встроенный GPRS стек, прием - отсылка SMS и CSD. Процессор питается от своего LDO на 3.3V.