Jet-Link Ultra отладчик неплохой, верой и правдой служит уже не первый год, но сейчас к нему есть наблюдения...
Есть два устройства - Master и Slave, реализованы на STM32F103 и общаются по RS-485. Master посылает пакет из нескольких байтов и принимает отклик от Slave'а. Программно реализован контроль передачи пакета ЧЕРЕЗ ПРЕРЫВАНИЯ с помощью USART3 на скорости 9600 Бод. Пока не подключаю отладчик, все замечательно работает.
Теперь делаем следующее:
1. Ставим log breakpoint в соотв место обработчика прерывания по флагу TXE, чтобы выдавался лог по факту передачи каждого байта. Осциллом садимся на TX вывод STM32F103 и видим, что байты передаются не пакетом, а с задержками около 10 (!!!) ms после каждого байта. Выключаем log breakpoint и видим, что байты передаются пакетом как и положено.
2. Ставим log breakpoint в соотв место обработчика прерывания по флагу RXNE, чтобы выдавался лог по факту приема каждого байта. Вижу только прием первого байта пакета...

Вопрос: в чем причина такого поведения? Скорость соединения 2МГц (так написано в панели jet-link'а). Должно же быть все быстрее?

A JetLink как соединяется?
через USB? Там наверное, USB Full Speed и пакеты идут один в миллисекунду?
Один байт - один пакет.
Ы?

И это, TXE/RXNE если память не изменяет, они вроде автоматически обнуляются после обращения к буфферу?
Здесь тоже могла собака порытся: отладчик прочитал, флаг сбросился, все застряло

Да, отладчик соед по USB и кабель должен быть очень хороший и короткий. Поначалу соединял его первым попавшимся - так он работать не хотел, пришлось раскошелиться на специальный full speed.
Совершенно верно, у STM32F1 USART флаги сначала анализироваться должны, а потом считываться байт (при приеме). Ессно, я ставлю log break ПОСЛЕ считывания байта в прерывании, так что здесь вроде все честно...
Пробовал и JTAG и SWD - разницы нет. Особенно удобно смотреть при передаче байтов с осциллом на пине TX: тока вкл log - сразу "растягивается" пакет, выкл. log - пакет "смыкается".
Для контроля передачи байтов такое поведение еще допустимо - SLAVE спокойно принимает байты с задержками, но когда он выплевывает ответ - ясное дело, Master с подключенным отладчиком и log'ом просто не успевает нормально принять все байты после первого...
Неужели никто не сталкивался с таким эффектом? Или я в опциях проекта галку какую-нибудь забыл поставить?

Не должно, 10мс не так и плохо. Не надо путать скорость с пингом.
И вообще отлаживать прерывания жилинком последнее дело.

Тогда выходит, что сеть RS-485 не отладить принципиально - на какой мастер или слэйв ни ткнись - посмотреть например наличие битых пакетов в сети принципиально невозможно?
Теоретически, при достижении log breakpoint отладчик должен выполнить простое действие - прочитать несколько байт. Сомневаюсь, что с такими высокоскоростными интерфейсами на это может уйти 10ms ...

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

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

Так что поднимайте еще один UART, выводите его на компьютер и смотрите что там происходит!

Хорошим тоном сделать сразу 3 уровня отладки
1. без отладки в порт ничего не пишется
2. только ошибки, в порт пишется только диагностическая информация, найденные ошибки
3. полная отладка, пишется все и принятые сообщения и ответы.

сразу делаете функцию SendDebug(FLAG, Data);

и дефайните ее на 3 уровня, в 1 случае делаете ее пустой
во 2, 3 случае по FLAG определяете это ошибки или полные сообщения и делаете пустой нужную функцию...

Да все это понятно, вопрос стоял не об этом, а верно ли поведение jet-link'а или что-то не так настроено в связке IDE - отладчик.