Поиск бага

[dgrishin]

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

Это только ваши догадки . CMSIS написана профессиональными программистами и код там самый правильный. ИМХО логирование вам мало поможет - т. к. зависание может быть вызвано некорректными таймингами при работе с периферией - а логированием (добавлением инструкций) вы их можете сделать правильными
Можно попробовать поднять SYSCLK до 72МГц и всё остальное вслед за ним и посмотреть как программа будет выполнятся.

[bass1981]

Это только ваши догадки . CMSIS написана профессиональными программистами и код там самый правильный. ИМХО логирование вам мало поможет - т. к. зависание может быть вызвано некорректными таймингами при работе с периферией - а логированием (добавлением инструкций) вы их можете сделать правильными
Можно попробовать поднять SYSCLK до 72МГц и всё остальное вслед за ним и посмотреть как программа будет выполнятся.

Улыбнули...
Windows тоже не дураки писали, насколько помниться на какой то из презентаций был синий экран... )))
Если вы утверждаете что в вашем софте нет багов - то вы не правы , они просто еще не найдены...
Мне приходилось править CMSIS , все заработало . Через месяц открываю проект, говорит что обновленная версия данного пакета есть скачать ?
Сделал копию , скачал бага нет...

Про тайминги писал выше и вы правы...

И попробуйте скормить CMSIS указатель на не существующий буфер ....
Посмотрите на эфект...

А хотите проектик под 415 накидаю всего HID и USART... И вот если не сделать задержку между приемом по USART и отправкой в USB - exeption... Код работает в 4ой версии на 415 и в 5ой на 103ем ...

[dgrishin]

И попробуйте скормить CMSIS указатель на не существующий буфер ....

Это как в анекдоте про японскую бензопилу и суровых русских мужиков.
"...И положили они под пилу рельс..."

[mike-y-k]

bass1981, адрес на I2C имеет вид 0bxxxxxxxy, xxxxxxx - 7 бит адреса, y - направление передачи (0 - write slave, 1 - read slave). Каждый продукт для I2C имеет свой адрес/набор адресов. В последнем случае есть дополнительные ноги для его модификации с двоичной/троичной/иной кодировкой (смотрим по DS). Адрес передаётся в первом байте посылки. Экзотический широковещательный режим естественно не рассматриваем . Расширитель портов в нашем случаье формально и есть регистровая 8 бит память, состояние которой изменяется командами записи от master. Состояние при включении будет на ввод и данные 0xFF. Этот код не стоит использовать . Ну и его чтение говорит о первой итерации после POR.

dgrishin, если такое логгирование изменит ситуацию - то так ему и быть, лишний килобайт кода "не спасёт отца русской революции"(c). А висящий индикатор поможет таки отследить ситуацию при снижении ее частоты до недель/месяцев.

Если алгоритм инициализации I2C немного наделить интеллектом, то вполне можно будет и дальше пойти. Тогда придётся немного больше таких мелкосхем использовать (до 8 штук). И при инициализации считывать весь набор адресов для определения состояния такого стека регистров с записью сохранённого в очередной свободный.

Вот тут под рукой оказалась ардуинка с STM, попробовал с ней ночью - на 4 корпусах регистров нормально отработало сохранение кода (по кнопке reset, вместо WDT ).

Итого можно будет использовать 253 контрольные точки (0x00 и 0xFF стоит пропустить).
Значение кода на светодиодах будет инверсным (через балластный к питанию).

[bass1981]

bass1981, адрес на I2C имеет вид 0bxxxxxxxy, xxxxxxx - 7 бит адреса, y - направление передачи (0 - write slave, 1 - read slave). Каждый продукт для I2C имеет свой адрес/набор адресов. В последнем случае есть дополнительные ноги для его модификации с двоичной/троичной/иной кодировкой (смотрим по DS). Адрес передаётся в первом байте посылки. Экзотический широковещательный режим естественно не рассматриваем . Расширитель портов в нашем случаье формально и есть регистровая 8 бит память, состояние которой изменяется командами записи от master. Состояние при включении будет на ввод и данные 0xFF. Этот код не стоит использовать . Ну и его чтение говорит о первой итерации после POR.

Чуть чуть про нюанс забыли со скоростью... Под рукой исходников нету... Надо для начала посмотреть на какой скорости там все работает...

А зачем 8 то .... ??? Две поставить 65000 комбинаций... Правда пр и логировании будет времени тратиться на запись в два адреса...

[mike-y-k]

bass1981, предложенный чип на 100kHz работает и на шине у каждой пары собственная скорость (SCL). Время на одну операцию на шине 20 тактов на 100kHz ~ 5ms.
И я не предлагаю писать в 2 сразу, а только при инициализации проверять и перезаписывать текущий в свободный. Появление индикации на втором и последующих будет показывать последнюю КТ в предыдущем до WDT/reset состоянии.
А 0xFF в рабочем признак запуска в первый раз.
Можно и более быстрые чипы посмотреть, я исходил из своего наличия .

[dgrishin]

Ещё один способ навскидку - написать свои обработчики (HardFault_Handler, BusFault_Handler и UsageFault_Handler) в которых сохранять в NVRAM е или в SRAMe адрес, с которого они были вызваны. А потом проанализировать код по этому адресу.

[bass1981]

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

backup домен !!!

Сейчас занят, вечером читать буду что там с записью и т.д ...

Оставляем вач ...

Сброс по питанию очищаем всю память... (например в 00)..
0 не используем...
Происходит сброс по ватчу , смотрим первый байт занят начинаем писать во второй и т.д..

Запускаем устройство... Через неделю приходим снимаем журнал через усб....

Только надо глянуть на скорость записи туда и нет ли ограничений по кол-ву записей....

[mike-y-k]

dgrishin, а как быть с WDT? И ошибка может быть просто в бесконечном цикле, а исчерпание WDT даст просто сброс.
Алгоритм должен быть в итоге минимально зависим, воспроизводим,…
Вариант по принципу POST в итоге оптимальнее.

[bass1981]

Ещё один способ навскидку - написать свои обработчики (HardFault_Handler, BusFault_Handler и UsageFault_Handler) в которых сохранять в NVRAM е или в SRAMe адрес, с которого они были вызваны. А потом проанализировать код по этому адресу.

По подробнее если не сложно...

void os_error (uint32_t error_code) {
  /* This function is called when a runtime error is detected.  */
  /* Parameter 'error_code' holds the runtime error code.       */

  /* HERE: include optional code to be executed on runtime error. */
  switch (error_code) {
    case OS_ERROR_STACK_OVF:
      /* Stack overflow detected for the currently running task. */
      /* Thread can be identified by calling svcThreadGetId().   */
      break;
    case OS_ERROR_FIFO_OVF:
      /* ISR FIFO Queue buffer overflow detected. */
      break;
    case OS_ERROR_MBX_OVF:
      /* Mailbox overflow detected. */
      break;
  }
  for (;;);
}

А за наводку спасибо, сюда можно вставить также логирование....
Так вы имели ввиду ???
Но ошибка может вообще банально быть в прерывании .... Например взят и не сброшен некий флаг при вызове прерывания и прерывание начинает вызваться постоянно ... Соответственно главный цикл перестает свое выполнение....