[Dr.Alex 0]

Соответственно тогда нужна и прога (для ж-линка или ст-линка), которая отображает то что валится из контрошки по SWO.

 

Сеггеровский SWO Viewer, наскока я вижу, хочет сначала прицепиться к таргету зачем-то, а потом наверное начнёт работать.

А зачем это надо, если SWO всё равно однонаправленный?

Казалось бы, лови всё что валится, как по UARTу, и всё.

[RusikOk 1]

не могу утверждать что дело не в моих руках но у меня при выводе через SWO без программатора контроллер стопорится

[Alechek 0]

Сеггеровский SWO Viewer, наскока я вижу, хочет сначала прицепиться к таргету зачем-то, а потом наверное начнёт работать.

Разве? А я и не заметил - подцеплял вживую (LPC1788), ничего не стопорилось, вывод был. Главное, частоту правильную указать.

Правда, гуишный падал постоянно, консольный, вроде, дольше жил.

 

[GenaSPB 11]

Если что - вот из CMSIS функция выдачи символа

 

/**
  \brief   ITM Send Character
  \details Transmits a character via the ITM channel 0, and
           \li Just returns when no debugger is connected that has booked the output.
           \li Is blocking when a debugger is connected, but the previous character sent has not been transmitted.
  \param [in]     ch  Character to transmit.
  \returns            Character to transmit.
*/
__STATIC_INLINE uint32_t ITM_SendChar (uint32_t ch)
{
  if (((ITM->TCR & ITM_TCR_ITMENA_Msk) != 0UL) &&      /* ITM enabled */
      ((ITM->TER & 1UL               ) != 0UL)   )     /* ITM Port #0 enabled */
  {
    while (ITM->PORT[0U].u32 == 0UL)
    {
      __NOP();
    }
    ITM->PORT[0U].u8 = (uint8_t)ch;
  }
  return (ch);
}

[AVI-crak 0]

Сеггеровский SWO Viewer, наскока я вижу, хочет сначала прицепиться к таргету зачем-то, а потом наверное начнёт работать.

Чтобы задействовать тактирование, и вписаться в 5% допуска. Иначе частота может получится любой, и детект на приёмной стороне будет намного сложнее.

Мне просто интересно, зачем внезапно понадобился SWO в автономном режиме? На чипе просто дофига аппаратных интерфейсов, нет - будем ногодрыгать через swo.

Изменено 4 ноября, 2016 пользователем AVI-crak

[RusikOk 1]

Мне просто интересно, зачем внезапно понадобился SWO в автономном режиме? На чипе просто дофига аппаратных интерфейсов, нет - будем ногодрыгать через swo.

чтобы не разводить отдельно. SWO часто уже разведен на разъем программатора. да и иногда интересно в терминале понаблюдать как ведет себя железка

 

[AVI-crak 0]

И убить статикой нормально работающий дорогой девайс? увольте.

Если хочется снимать логи, для этого есть куча возможностей. Начиная от варта с оптической развязкой, заканчивая запаянным на пузо чипом esp8266, без платки он занимает минимальное пространство. А мой последний логгер общался через вч пищалку, потому как висел на шине в десятки киловольт (буквально).

 

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

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

Это как замок на трансформаторной будке, все знают что может убить - но без замка идиоты всё-же находятся.

[Dr.Alex 0]

На чипе просто дофига аппаратных интерфейсов, нет - будем ногодрыгать через swo.

 

Вам нужно ногодрыгать, вы и ногодрыгайте, и не надо приписывать своих глупостей мне.

 

ITM это и есть стандартизованный аппаратный интерфейс, и мой вопрос именно об его использовании по назначению.

 

Он уже выведен на разъём, а на столе уже лежит ж-линк. Почему я должен изобретать велосипед?

 

Для остальных пишу по существу:

 

Некоторое изучение темы показало, что ARM немного облажались и не предусмотрели возможности ПРОГРАММНО переключить ITM из режима JTAG в режим SWD/SWO, для этого якобы надо немножко подёргать лапами JTAG извне.

Пруфлинки:

 

https://my.st.com/public/STe2ecommunities/m...urrentviews=114

 

https://community.arm.com/thread/2519

 

Но и с этим полной ясности нет.

 

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

[AVI-crak 0]

В моём понимании "выключен" - снято питание.

Режим сон - есть питание, выключена периферия и остановлено ядро. Если отключить ещё и память (нет смысла) - то для отладочного интерфейса остаются регистры ядра.

Режим стоп - остановлено ядро (потребление почти ноль), работает необходимая периферия. Из этого режима можно отладочным интерфейсом читать память. Насколько я верно понял - вам именно это и нужно.

Есть выход, http://www.emblocks.com/forum/viewtopic.ph...89282df567ec09e

Там всё просто. Есть буфер - который заполняется сообщениями от системы, есно когда она работает. Отладочный интерфейс читает этот буфер с максимальной скоростью без остановки ядра, как обычную память. Общаться можно в обе стороны. Этот режим отладки идеально подходит для систем реального времени.

 

Хотя мне проще задействовать четыре контакта для варта, и через оптику.

 

Насчёт ногодрыга, отправка сообщений через SWO - лишь частично аппаратная, проверку условий необходимо выполнять ручным способом. Это означает что таск работающий с отправкой сообщений - будет выполняться со скоростью физического порта.

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

 

[Alechek 0]

Насчёт ногодрыга, отправка сообщений через SWO - лишь частично аппаратная, проверку условий необходимо выполнять ручным способом. Это означает что таск работающий с отправкой сообщений - будет выполняться со скоростью физического порта.

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

1. Скорость SWO, как правило, выше чем скорость UART.

2. Бывает так, что все UARTы заняты...

 

[demiurg_spb 0]

https://github.com/yurovsky/swo-tracer