Integro

IoT(Internet of things) никакой интерфейс не подразумевает, это концепция сети, не больше!

Опеределен в стандарте С99: 7.18.1.3 Fastest minimum-width integer types http://www.dii.uchile.cl/~daespino/files/Iso_C_1999_definition.pdf Стыдно Вам должно быть за такие слова!)

Я скажу так: В середине нулевых, WIZnet отлично решал проблемы в разработках на PIC, AVR, 8051 и других MCU с малым количеством RAM и ROM (ну и понятно без MAC). В те времена ленивые программисты могли делится на программистов ATMEL(которого уже нет) и Microchip и переходить на другой контроллер им совсем не хотелось вот тогда в дело вступал WIZnet, одна микросхема и твой PIC16 в локальной сети, тогда даже к интернету его проблемно было подключить, так как даже корпоративные сети не всегда имели доступ в интернет. Сегодня WIZnet активно распространяется как sheild к arduino uno, так как только там для той старой доброй атмеги он и нужен. Сегодня у каждого производителя в линейки есть контроллер с MAC (а у кого то даже и с PHY). Куда надежнее и гибче использовать софтовый TCP\IP стек чем аппаратный. Сегодня Ethernet разъем в "IoT устройстве" это дикость. А если вам нужен ethernet в проекте то это наверняка уже гигабитные скорости. Сегодня W5500 подходят только для управлением\контроля устройством, заявленные 80MHz еще нужно запустить, как они пишут (страница 64) максимально гарантированные 33MHz! Пытаюсь придумать случай для применения их чипов и на ум приходит только ситуации(утрируя): 1. Когда скажем на складе контрактного разработчика завалялись 5К шт. контроллеров STM8, приходит проект, скажем управлением сетью шлагбаумов на такое же кол-во изделий, берем эти STM8+WIZnet+NFC и т.п. 2. SoC для мобильных\носимых устройств, как правило не имеют MAC, сюда можно поставить WIZNet и привязать ваш носимый девайс к ethernet шнурку. 3. Домашние поделки с Arduino, например, контроль питанием и управлением домашнего сервачка или свитча на крыше, если такой еще остался. 4. А, ну и случай когда на складе завалялись 5К штук W5xxx... @jenya7если Ваш аргумент "я быстро запустил пример", то я бы всетаки порекомендовал потратить время и изучить доступные TCP\IP стеки и быстро запускать софтварные стеки

Как показывает практика, подвиcает не блок микроконтроллера, а один из slave'вов держит линию данных в нуле. Лечится ручным дерганьем клока, или генерацией старт-стопов пока SDA не придет в норму. Но и ресет I2C я тоже в этих случаях добавляю.

Уважаемый @jcxz, я Вас услышал! Бросайте уже это привычку в обсуждении проблем ТС отступать от темы и повествовать о вашей реализации не касающейся проблемы. У ТС уже есть своя реализация и нужно чинить ее! Мы даже не знаем включен ли там TICKLESS. Если Вы хотите обсудить использование memory barriers предлагаю создать отдельную тему! Здесь мы имеем FreeRTOS где уже реализован механизм сна через TICKLESS, и если он включен и это версия 7.х то нужно делать так как я писал, иначе получим HF!

Есть подвижки? Если со стеками все ок, предлагаю обсудить маловероятные причины Вижу, Вы ответили, что сон не используется, но переспрошу, этот configUSE_TICKLESS_IDLE дефайн в единице? Если да то как я уже писал, WFI нужно обернуть в DSB и ISB, подсмотреть можно в новых версиях port.c Мало вероятно но все же, как вариант, можно выключить FPU, посмотреть изменится ли поведение. Не знаю что там в 7.4 но в более старых FreeRTOS точно были проблемы с контекстом FPU.

Есть три варианта решения проблемы: Через linker, чтобы автоматом в момент сборки на выходе получить готовый файл прошивки. Как это сделать, зависит от компилятора который Вы используете и о котором нам не известно. Предварительно преобразовав ваш image в С массив(используя стороннюю тулзу, на выходе будет image.h) и подключив его к проекту через #include, и опять же средствами линкера разместить его по указанному адресу. Это все справедливо если Вы используете С о чем мы тоже не знаем, если ASM подход тотже но с таблицей символов как написано выше. После компиляции склеить выходной bin(или hex) с вашим image по нужному смещению, тоже используя сторонний инструмент Последних два пункта можно привязать к пре или пост билду, что избавит Вас от дополнительных движений.

Так вроде как известная тема, про DSB и WFI а здесь про интеррапты и ISB FreeRTOS например, так с 8 версии делает

Нужно больше инфы! - Какая версия FreeRTOS? - ASSERT включены? Полезны! - Tiсkless включен? или может в коде есть прямой переход в Sleep(вызов WFI)? WFI обвернут в DSB и ISB? - Контроль переполнения стека средствами FreeRTOS включен, 1 или 2? - Что со значением MSP и PSP? Не выходят ли за границы? Вершины стеков выравнены по 8? - FPU включен? используется? Как это понимать: Какие компоненты(питание или периферия)? Возможна ли генерация дополнительных прерываний(или на оборот) на этих платах? Какие интерфейсы задействованы? Ревизия MCU та же? Буквально та же самая, байт в байт? Ну и стандартные ошибки, нужно посмотреть в сторону возможности работы с нулевым указателем на какой либо объект, либо выход за границы массивы при копировании данных или работы DMA.

Вчера был официальный релиз: https://www.st.com/content/st_com/en/about/media-center/press-item.html/p4117.html

нуда, понял Всмысле точно? Перед входом в исключение я могу совершенно "штатно"(случайно) затереть стек и при этом исключение может сработать только при выходе функции (или еще дальше) а не в момент затирания стека. void test(void) { uint8_t dest[1000]; uint32_t src[1000] = {0}; memcpy(dest, src, sizeof(src)); printf("complete"); } В этом случае в стек фрейме будут нули но в LR будет лежать PC+1, адрес в момент HF.

PC ведь указывает на текущее положение, на ту строку дизассемблера которая сейчас выполняется. Нужно смотреть на LR или проще посмотреть callstack если он не затерт

Cмысл исправлять на __packed если они потом приводят к типу (void*) ?

Нужно

В данном примере, вероятно, ключевой момент был в (void *)packed_ptr, после этого компилятор будет использовать байтовый __aeabi_memcpy #include <string.h> unsigned int * const dest; void example (unsigned int * const unaligned_ptr) { __packed unsigned int * packed_ptr = unaligned_ptr; char * temp_ptr = (char *)unaligned_ptr; memcpy(dest, unaligned_ptr, 32); /* Unsafe */ memcpy(dest, (void *)packed_ptr, 32); /* Safe */ memcpy(dest, temp_ptr, 32); /* Safe */ } Не совсем понятно какую цель они преследовали добавив туда __packed, возможно что-бы явно показать что packed_ptr может быть не выровнен, о чем можно прочитать здесь