GREGOR_812

Не уверен, что вопрос ещё актуален, но на всякий случай выскажу свои мысли:

1. Возможно, ваш девайс присылает слишком короткое сообщение и ждёт ответа. Чтобы это проверить/исправить, вы можете поиграть с порогом ReceivedBytesThreshold, которые есть у типа SerialPort. Это порог по кол-ву данных в буфере чтения, по достижению которого будет срабатывать событие DataReceived, на которое вы подписались. Поставьте брейкпойнт на строке string _message = null; в обработчике DataReceirvedDt и проверьте, вызывается ли вообще этот обработчик для ардуины про. Если нет, значит, нужно уменьшать порог.

2. Если же с порогом всё ок, то идём дальше. В обработчике При чтении методом ReadLine() нужно быть точно уверенным, что у вашего хоста и ардуины про одинаковые символы окончания строки. Для хоста это можно настроить через свойство NewLine в классе SerialPort. Судя по коду, у вас хост под виндой, значит, окончание строки у вас может отличаться от того, что присылает ардуина. Если они не совпадают, то метод не может найти окончания строки и блокируется. Чтобы это проверить, можно поставить брейкпойнт на строку _message = serialPortData.ReadLine(); и выполнить его кнопкой StepOver в отладке. Если данные будут получены, значит окончание строки на хосте и ардуине интерпретируется одинаково, если метод заблокируется, значит, либо в полученных данных вообще нет символов конца строки, либо они различаются у хоста и ардуины.

Делайте это не в Immediate Window, а в Watch

Насчёт 30 страниц -- это явно преувеличение. Такой контроллер бы просто никто не покупал и его отозвал бы производитель, ибо на порче имиджа он потеряет больше денег, чем на отзыве партии.

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