Andy_Mozzhevilov

Так и есть. В USB данные будут ходить с той скоростью, сколько USB позволит. То, что вы устанавливаете, это фактически настройки для реального COM порта, который может торчать с другой стороны USB. Они уходят отдельными командами и могут быть использованы, если нужно. Например можно сделать конвертер USB-COM и по переданным параметрам устанавливать нужную скорость UART.

а __iar_system_Mtxinit у вас вызывается при инициализации системы? Можете в отладчике это проследить? И еще, как идея, посмотрите про опцию линкера --threaded_lib

Я не думаю, что вы найдете какую-то универсальную платформу "на поиграться" с такими характеристиками, потому что то, что вы ходите обычно не делается универсальным, а проектируется под конкретные требования к сопряжению с какими-то реальными датчиками и объеками управления.

Все зависит от того, что вам требуется. Какой-то субмодуль, где разведена память и процессор, к примеру, или закончанная плата для какого-то специального применения.

Еще добавлю, что как правило TVS не ставят прямо на вход цепи, в которую приходит МИП. TVS ставят уже как второй каскад защиты, а в первом лучше ставить либо варисторы, либо разрядники, либо их комбинацию, в зависимости от защищаемой цепи. Вы бы схему входной цепи привели, чтобы было понятно о цем речь.

Как правило в характеристиках элементов защиты от импульсных перенапряжений указывается и формы импульса тока, для которого приведены их характеристики. В ГОСТ также указана форма импульса тока испытательного генератора для случая его работы в режиме КЗ выхода. Вот вам нужно все это вместе свести и выбрать элемент защиты или цепочку из них.

Определите, какое выходное сопротивление генератора помехи будет применяться для ваших цепей. По ГОСТ может быть 3 варианта: 2 Ом, 12 Ом и 42 Ом. Если речь идет о цепях ввода-вывода, то скорее всего речь будет идти о 42 Ом. Исходя из этого определяйте ток, который должен пропустить через себя элемент защиты, падение, которое на нем будет при этом токе, соответственно будете знать рассеиваемую мощность. Дальше по этим параметрам выбираете нужный элемент или составляете схему из них. МИП - достаточно простая и предсказуемая помеха, разве что мощная.

Требование к сопротивлению изоляции предъявляется к цепям, находящимся под напряжением. В зависимости от величины напряжения есть требования к прочности. То, о чем пишете вы - относится к цепям электропитания 220В. Тут вроде как вопрос по гальванически-изолированным низковольтным цепям. Типа сделали развязку через DC-DC и оптроны интерфейсных схем. Там напряжение в этих цепях не превышает обычно 12В, то есть ниже 48, а для таких цепей требования к прочности изоляции либо не предъявляются, либо они ниже (500В по-моему, не хочется в ГОСТ сейчас лезть). Что касается испытаний на прочность изоляции устройств, где предусмотрены элементы защиты, особенно по питанию со стороны 220, то в этом случае при испытаниях на прочность элементы, установленные для обеспечения ЭМС, удаляются. Это тоже где-то в ГОСТе было.

Читайте тут касательно того, по каким интерфейсам можно заливать флеш через встроенный бутлоадер, USB там тоже есть. http://www.st.com/web/en/resource/technica.../CD00167594.pdf По схеме SK-STM32F417, которую я бегло просмотрел, можно джампером J8 поставить на BOOT0 лог.1, а BOOT1 затянут резистором к нулю. Таким образом получаете активацию системного бутлоадера. Дальше конфигурируете джамперами USB так, чтобы USB-В разъем подключался к PA11 и PA12 портам (тоже это можно сделать, судя по схеме). Ну и все должно заработать для загрузки по USB через DFU. Вопрос такой, если получится, отпишитесь. И что за софт используется для загрузки по USB в этом случае? Бегло искал на ST информацию по этому поводу, но не нашел. Особой надобности не было, правда. А вообще лучше через JTAG или SWD зашивать флеш при отладке, это удобнее гораздо.

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

Чтобы послать баг с надеждой на его исправление и не имея тех.поддержки крайне желательно его локализовать в неком очень небольшом коде, который бы собрался в составе мелкого проекта, созданного в IDE IAR, архив которого им и отсылать. В вашем же коде просто кусок из программы, который не соберется. А если начать выкидывать что-то, может и баг исчезнуть. Собирайте проект в 5.50, а отладку запускайте хоть в 6.40. Там все совместимо по форматам out файлов. Главное, чтобы сам компилятор мог делать код для нужного ядра. на 6.30 тоже его нет.

Как вы определяете факт старта платы? У вас есть динамическая инициализация, т.е. вы используете С++ и глобальные объекты классов, или у вас чисто С код? Те 20-30 секунд, когда плата находится в непонятном для вас состоянии, осциллятор запускается? Все это происходит только по включению питания, или нормально заработавшая плата может в такое состояние переходить, если ей дернуть Reset?

Вы все же разобрались, стартует у вас бутлоадер, ваш код, или ни то и ни другое и контроллер находится в каком-то неопределенном вами состоянии? Не понятна фраза "Ресет так же не помогает и в течении секунд 20-30 программа нормально стартует." Может кратко в одном посте можете описать последовательность действий и состояний контроллера?

Я достаточно давно ловил баг еще в какой-то 4-й версии компилятора и отправлял им, официальной поддержки не было, ессно. В следующей версии компилятора баг был поправлен, не знаю уж, по моему репорту или нет. Я email посылал не с просьбой о поддержке, а именно как bug report. В конце концов это в их интересах улучшать компилятор. Во всяком случае попробовать надо, особенно если баг хорошо локализован на небольшом участке кода.

Чтобы поправили, надо бы им в поддержку отписать. А то ж они - не телепаты.

Вам нужно поместить инициализированный массив в секцию, а затем линкеру указать, в какие адреса эту секцию положить. struct Slon_s { uint32_t var_a; uint32_t var_b; }; #pragma section="SECTION_MY_SLON" #pragma location="SECTION_MY_SLON" const struct Slon_s Slon = { .var_a = 1, .var_b = 2 }; в icf файле: define symbol MY_SLON_ADDR = 0x00007e00; place at address mem:MY_SLON_ADDR { readonly section SECTION_MY_SLON}; keep { section SECTION_MY_SLON }; /* Это надо, только если из программы нет явных обращений к переменной Slon */ как-то так

Вы где-нибудь на этапе до всякой инициализации в ПО на неиспользуемой внешней ноге установите уровень, по которому можно посмотреть скопом, проходит проц этот участок кода или нет. Если используете IAR, то лучше сделать в __low_level_init в самом начале, для других кросс-компиляторов должны быть подобные механизмы, или стартап поправить. Вы таким образом практически однозначно определите, стартует у вас контроллер из флэш и выполняет ваше ПО, а потом виснет, или сваливается в бутлоадер. Если вы используется C++, то проблема может заключаться в конструкторе глобальных объектов, которые вызываются при инициализации системы. Да мало ли там еще может быть причин. По вашим постам не совсем понятно, как и где вы инициализируете систему и что у вас там наворочено.

Можете ссылку на исходники дать? Пошарил в инете, явно нашел только прекомпилированные библиотеки.

У вас скорее не оптрон открывается, а помеха через паразитную емкость напрямую проходит дальше в схему. Оптроны для защиты от НС сами по себе практически бесполезны.

Для сброса нужно просто в wdt записать неправильную последовательность, не обязательно ждать таймаута по нему.

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

Для чего? Оно же не сможет участвовать в арбитраже и поэтому не будет соответствовать стандарту CAN. То есть потенциально оно может вклиниться в шину и разрушить все, что там происходит в данный момент. Сдается мне, что вы сильно "плаваете" в мат.части, оттого вопросы ваши непонятны, терминология сумбурна и не соответствует стандартной. Отчего помочь вам в решении вашей проблемы сильно затруднительно.

Чушь полная. Если только на низких скоростях (и то не при помощи SSP), и то неясно, зачем такое извращение. PS: Автору топика. Если у вас именно в bus-off вываливается, то ищите где. Подключенный в listen only узел не должен никак влиять на шину. То есть можете вообще нагрузить кабель терминаторами, и передавать пакеты, эффект с точки зрения передатчика должен быть таким же, как и при наличии на другом конце узла с listen only. При всем этом, как вам выше сказали, в bus off передающий контроллер не будет падать, только в error passive. Сам Listen only узел CAN будет принимать сообщения только в том случае, если на шине существует нормальный обмен, т.е. CAN пакеты подтверждаются принимающими узлами, находящимися в активном режиме. ЗЫ: Почему прием нужно осуществлять именно в listen only? Какой в этом глубокий смысл? Почему нельзя перевести принимающий узел в активный режим?

Так эти от 50 кГц, на не Гц.

// __iar_data_init - функция из библиотеки, выполняющия фазу static segment initialization // Для разных версий функции инициализации сегмента данных вызываются по разным именам // __VER__ - предопределенное макро в IAR, см. документацию на компилятор #if __VER__ <= 5011000 /* Для IAR 5.11 */ extern __interwork void __iar_data_init(void); /* Для IAR 5.20 и выше */ #elif __VER__< 5050005 extern __interwork void __iar_data_init2(void); #elif __VER__<= 6010001 // Версия Iar с 5.50.5 по 6.10.1 extern void * __iar_cstart_call_ctors(void *ptr); extern __interwork void __iar_data_init3 (void); #else // Версия Iar выше 6.10.1 #error Untested init sequence for this compiler version #endif