SIM300D перезагружается и втупляет, Я всё читал и делал, но до сих пор ничего не помогло Опции

[Spider]

SIM300D вроде с первого взягляда работает. Но стоит начать передавать данные, как он перезагружается. Как всё происходит.
Имею 2 разные прошивки для своего контроллера. Одна рботает со встроенным стеком TCP, вторая сама работает с PPP/IP/TCP. Обе имеют один симптом - перезагружается SIM300D.
При работе со встроенным стеком перезагружается "иногда" после AT+CIPSEND. т.е. > появляется, пишем туда данные, от силы байт 60, "жмём" Ctrl+Z (на самом деле посылаем 0x1A) и... и ничего. вмето ожидаемого SEND OK, получаем "прыжок" STATUS и Call Ready со всем вытекающим.
Похожая ситуация с моим TCP, процессе передачи данных иногда, по случаю, модем делает то же самое.
Как я уже сказал я перечитал все факи м замучил Кадило (спасибо за терпение).
Из того что уже сделано:
т.к. общается с модемом ATMega128 питаемая 5 вольтами, то между модемом и процом стоит 74HC/HCT243 в кол-ве 2 шт. OEb которых прицеплено к STATUS. Ну конечно же запитаны они от 3.3В и 5В соответвенно направлению линий. И на ногах к модему резюки 150Ом. Этим самым я обепечиваю преобразование уровней до 3.3 и Z статус когда нет STATUS.
Модем питается от LM1085-ADJ настроенной на 4.13В (так получилось фиксированными резюками). После неё идёт Тантал на 220uF (чёрный такой ) и керамика на 16uF (опять же какой нашёл на пробу), да да керамика в корпусе 1206.
Так же я пробовал вместо LM1085 подключать Li батарею от сотового.
Модем тушим "корректно" - АТ командами и ожидаем NORMAL POWER DOWN.
Прошивка B14.
Скорость общения по UART 115200 со всеми линиями данных RTS/CTS DCD/DSR

Это лечится??? ХЕЛП!!!!

[av-master]

правильный преобразователь - отключаемый? а то даже 2.9 может быть много, питание ядра 1.8

Сообщение отредактировал av-master - Mar 17 2009, 20:30

[SV_TC]

правильный преобразователь - отключаемый? а то даже 2.9 может быть много, питание ядра 1.8

Извините, повторюсь: "...однако питание 2,99 В на преобразователь уровня цепей TxD и RxD подается не ранее 8 с после включения модуля."
Здесь "подается" - в том смысле, что пока не подано, напряжение равно нулю.

Неоднократно писали, что стоит поменьше конденсатор поставить, а не 100мкФ. Хотя все это шаманство.
Но попробуйте.

Казалось бы, если производитель (в руководстве) предлагает использовать для этой цели батарею или "large capacitance Capacitor" емкостью "0.2F to 0.3F", то чем же 100 мкФ хуже?
Однако попробовали 22 мкФ, затем 0,1 мкФ - проблема сохраняется.
Попутно вопрос: кто-либо пробовал или может опробовать выдачу через свой модуль на скорости 115,2 кбит/с в режиме UDP до 10-ти пакетов размером 512 байт - подряд (конечно, всякий раз - с подтверждением отправки)?
Напомню проблему: у нас модуль в этом случае перестает подтверждать отправку после 1...5 пакета. При передаче блока он ни разу не выдает Xoff, но выдает его примерно через 20 мс после передачи блока - и больше ничего: не передает Xon и не реагирует ни на какие команды. Помогает только рестарт питания модуля (конечно - правильный). Переводим модуль в режим RTS/CTS, наблюдаем за CTS: CTS в течение передачи блока находится в нуле, а примерно через 20 мс - переходит в единицу и модуль также "висит".
А вот на скорости 9,6 кбит/с этой проблемы нет.

[M_Z]

Попутно вопрос: кто-либо пробовал или может опробовать выдачу через свой модуль на скорости 115,2 кбит/с в режиме UDP до 10-ти пакетов размером 512 байт - подряд (конечно, всякий раз - с подтверждением отправки)?

Мы используем скорость 115,2 но TCP соединение. передаем подряд десятки пакетов естественно дожидаясь подтверждения SEND_OK, плюс подтверждения нашей программы на сервере что данные записаны в базу данных. и только после этого отправленные данные удаляем и шлем новый пакет.
Может у Вас какие то проблемы с оператором, но тогда не зависило бы от скорости передачи.