Jump to content

    

STM32F407 зависание UART4 периферийного модуля

Вы меня не так поняли. Такой подход как у вас у меня тоже используется в драйвере i2c. Я пытался сказать, что не вижу других способов кроме как использовать указатель на структуру или просто номер. Для меня номер в данном случае был предпочтительнее. Но на самом деле изначальный вопрос несколько иной:acute:

Edited by Neo_Matrix

Share this post


Link to post
Share on other sites
2 часа назад, Neo_Matrix сказал:

А volatile перед tmp_reg нужен для того что бы оптимизатор не выкинул пустое чтение регистра, которое необходимо для очистки флагов, попробуйте без него и будете потом долго искать почему флаги не сбрасываются, так что меня терзают сомнения, что у вас код намного лучше моего.

Ну ёшкин кот! Давай разберём построчно эту чушь:

volatile uint32_t tmp_reg;

Тут мы создали локальную переменную tmp_reg целого беззнакового 32-битного типа. В стеке, вестимо, так как локальная и volatile.

tmp_reg = read_reg(uart_data->uart_typedef, DR);

Из регистра USARTx->DR в эту переменную прочитали значение с обязательным сохранением в место хранения, так как она volatile.

(void)tmp_reg;

Прочитали значение переменной tmp_reg из места хранения, так как она volatile и результат выкинули.

 

Мой код, естественно, будет лучше

USARTx->DR;

Просто прочитаем из DR данные, так как регистры определены как _IO (читай volatile), а результат выкинем.

Share this post


Link to post
Share on other sites
6 минут назад, VladislavS сказал:

Мой код, естественно, будет лучше

Я абсолютно не спорю. Но подобный подход использую не только я, пример:

image.thumb.png.7983d9991ba475a3673c01110966642c.png

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

Edited by Neo_Matrix

Share this post


Link to post
Share on other sites

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

        
// USART1->DR;
        LDR.N    R0,??DataTable2_1  ;; 0x40011004
        LDR      R1,[R0, #+0]

Для сравнения

  volatile uint32_t tmp_reg;
  tmp_reg = USART1->DR;
  (void)tmp_reg;
//   volatile uint32_t tmp_reg;
//   tmp_reg = USART1->DR;
        LDR.N    R0,??DataTable2_1  ;; 0x40011004
        SUB      SP,SP,#+4
        LDR      R1,[R0, #+0]
        STR      R1,[SP, #+0]
//   (void)tmp_reg;
        LDR      R0,[SP, #+0]
        ADD      SP,SP,#+4

 

Всё ещё есть желание индусский код за образец брать?

Share this post


Link to post
Share on other sites
2 часа назад, VladislavS сказал:

 


volatile uint32_t tmp_reg;

Тут мы создали локальную переменную tmp_reg целого беззнакового 32-битного типа. В стеке, вестимо, так как локальная и volatile.

На кой ляд локальной автоматической переменной атрибут volatile? Разве тока если адрес на неё передаётся в другую задачу, чего вроде как нет.

2 часа назад, Neo_Matrix сказал:

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

Индусский код уже стал у нас образцом качества?  :shok:

2 часа назад, VladislavS сказал:

Всё ещё есть желание индусский код за образец брать?

хе! только сейчас прочитал. прям те же слова  :smile:

Share this post


Link to post
Share on other sites

В итоге упростил обработчик, написал его на голом доступе к регистрам, по рекомендациям выше. В итоге абсолютно нечего не изменилось. При этом, если тот же код использовать на USART2 - все отлично работает и "подвесить" периферию не получается. Вкрадываются подозрения, что это связано с разными модулями периферии APB2\APB1.

ПС: А с чего вдруг lwip стал внезапно индусским?

Edited by Neo_Matrix

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
22 minutes ago, Neo_Matrix said:

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

Я бы не спешил с выводами. Проверьте очень внимательно тактирование, настройки WS флеш и т.п. А то как бы на очередной партии проблема не вернулась.

Share this post


Link to post
Share on other sites

С тактированием все нормально, уже проверял. Косвенно можно судить о нормальном тактировании по ЮСБ который достаточно критичен к частоте. Задежки чтения флеша тоже правильные. Буду надеяться, что проблема решена. Есть еще вероятность, что в прошлой партии неправильно смонтажили компоненты, допустим керамику вокруг проца. Но выпаивать все и проверять - пока не готов.

Share this post


Link to post
Share on other sites
В 21.05.2019 в 19:11, Neo_Matrix сказал:

А с чего вдруг lwip стал внезапно индусским?

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

Share this post


Link to post
Share on other sites
5 часов назад, VladislavS сказал:

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

Я в курсе, что такое "индусский код". Просто стек популярный и достаточно навороченный, при своей нетребовательности к ресурсам(тут конечно все относительно).

Причина проблемы полностью выяснена. Виной странная партия процов. Как и писал ранее в новой партии устройств данной проблемы нет, потому я просто перекинул процы между 2мя устройствами, глюк перекочевал на другую плату вместе с процом, старая же плата с новым процом заработала нормально. Ревизия процов везде "2". Внешне процессора имеют небольшое отличие, глючные имеют блестящие выводы(похоже на покрытие ПОС), новые имеют более коричневый оттенок выводов(возможно иммерсионное золото, но не уверен).

Share this post


Link to post
Share on other sites
14 часов назад, Neo_Matrix сказал:

Причина проблемы полностью выяснена. Виной странная партия процов.

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

Ощущение, что проблема в чем-то другом ничуть не уменьшилось.

Share this post


Link to post
Share on other sites

Лажа таки в МК была, добавил костыль в код, для "отвисания". Проверено на всей новой партии более 100шт, такого глюка нет.

Share this post


Link to post
Share on other sites
  1. А в двух словах можно опсисать?
  2. А на старой партии процессоров костыль не помешал?

Share this post


Link to post
Share on other sites
1 час назад, GenaSPB сказал:
  • А в двух словах можно опсисать?
  • А на старой партии процессоров костыль не помешал?

Сама проблема была описана ранее(в первом посте). Переферийный модуль UART4 вис намертво пока не записать в DR любую инфу. На остальных юартах этой проблемы не наблюдалось.

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now