Слетает прерывание UART при работающем LWIP, плата Freescale FRDM-K64F Опции

[asm_lock]

Здравствуйте Уважаемые коллеги!!!
Возникла такая вот проблема.
Когда подключен сетевой кабель и происходит обмен данными по UART'у, через какое то время запрещается прерывание этого UART'а.
Если сетевой кабель не подключен, то UART работает без глюков.

Из-за чего происходит запрет прерывания ?

Заранее всем спасибо.

[ataradov]

Могу предположить случайный проезд по памяти.

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

[jcxz]

Если сетевой кабель не подключен, то UART работает без глюков.
Из-за чего происходит запрет прерывания ?

На 99.(9)% из-за багов в Вашем коде, но никак не из-за самого UART.

[asm_lock]

Могу предположить случайный проезд по памяти.

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

Я тоже так думаю. т.к. иногда отладчик ругается что не может прочитать память....
Просто часть прогарммы то работает, плата по сети пингуется...обмен по lwip происходит (снифером посмотрел)...отправка данных по злосчастному уарту идет но ни чего не принимает....
Как с этим бороться ?

[ataradov]

Как с этим бороться ?

Ну так если отладчик есть, то поставить точку останова на запись в этот регистр. Там и видно будет, кто его выключает.

[asm_lock]

Ну так если отладчик есть, то поставить точку останова на запись в этот регистр. Там и видно будет, кто его выключает.

Запись в какой регистр ????

Я сейчас пере инициализацию уарта поставил если прерывание будет запрещено...посмотрим как оно зафурычит..

Кстати, отлаживаю под eclipse (KDS_3.0.0)....там хрен что посмотришь....

ЗЫ: в NXP Community прочитал что при отладке, встроенный в плату J-Link подглючивает....память там не читает и т.д....

Сообщение отредактировал asm_lock - Mar 30 2016, 08:40

[jcxz]

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

Фразу "происходит запрет прерывания" в контексте данного топика не следует воспринимать буквально как "самопроизвольно снимается бит разрешения прерывания по событию опустошения или заполнения FIFO UART". Это исходя из формулировки вопроса.
Речь может идти от чего угодно, вплоть от банального переполнения стека или разрушения каких структур в памяти и улёта куда угодно, до как Вы указали - записи в управляющие регистры периферии, но не конкретный регистр, а какие угодно - от любого регистра конфигурирования UART, до регистров разрешения тактирования или питания UART либо любых других.
Так что бряк на доступ к памяти вряд-ли поможет.

Я тоже так думаю. т.к. иногда отладчик ругается что не может прочитать память....

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

PS: Совет - первым делом проверьте все стеки на предмет переполнения. И ищите баги в ПО методом исключения.

[asm_lock]

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

PS: Совет - первым делом проверьте все стеки на предмет переполнения. И ищите баги в ПО методом исключения.

Бряк стоит...в том то и дело...перезапуска не происходит. Крутимся в wile'.....

[AlexandrY]

Запись в какой регистр ????

ЗЫ: в NXP Community прочитал что при отладке, встроенный в плату J-Link подглючивает....память там не читает и т.д....

Смотреть надо регистр UARTx_C2.
Еще изменения в SIM модуле могут вызвать остановку работы UART: SIM_SOPT5, SIM_SCGCx..

Подглючивают любые отладчики если нарушить систему тактирования.

[jcxz]

Бряк стоит...в том то и дело...перезапуска не происходит. Крутимся в wile'.....

Если есть подозрения на несанкционированные записи в регистры конфигурации UART, то это можно отловить с помощью MPU, закрыв от записи соответствующий регион адресов.
Да заодно закрыть с помощью MPU и регион регистров управления системы тактирования и питания.

[AlexandrY]

Если есть подозрения на несанкционированные записи в регистры конфигурации UART, то это можно отловить с помощью MPU, закрыв от записи соответствующий регион адресов.

MPU не для этого.
У Kinetis есть специальный для этого блок - Peripheral Bridge (AIPS-Lite)

[jcxz]

MPU не для этого.
У Kinetis есть специальный для этого блок - Peripheral Bridge (AIPS-Lite)

Раз это Cortex-M, то MPU и для этого тоже можно использовать. Автору важно получить исключение при попытке записи в отслеживаемые адреса памяти. И узнать источник. MPU это позволяет.

[AlexandrY]

Раз это Cortex-M, то MPU и для этого тоже можно использовать. Автору важно получить исключение при попытке записи в отслеживаемые адреса памяти. И узнать источник. MPU это позволяет.

Нет. Почитайте как устроен MPU у Kinetis.

[jcxz]

Нет. Почитайте как устроен MPU у Kinetis.

Он устроен не как в других Cortex-M??? хм.... MPU вроде входит в ядро Cortex-M и должен быть устроен одинаково у всех.

[AlexandrY]

Он устроен не как в других Cortex-M??? хм.... MPU вроде входит в ядро Cortex-M и должен быть устроен одинаково у всех.

MPU в Cortex-M это только опция.
В Kinetis есть свой более умный MPU , но он не для обсуждаемой цели.

[asm_lock]

Поставил пере инициализацию уарта если UART_HAL_GetRxDataRegFullIntCmd(baseAddr) == false.

Не помогло....

[ataradov]

Не помогло....

Если "выключается прерывание" - это действительно не "пропадает флаг разрешения в регистре", а "вообще ничего не работет", то нужно действительно настраивать MPU и ловить левые обращения.

Не важно что для чего предназначено, для отладки любое MPU подойдет.

[asm_lock]

Если "выключается прерывание" - это действительно не "пропадает флаг разрешения в регистре", а "вообще ничего не работет", то нужно действительно настраивать MPU и ловить левые обращения.

Не важно что для чего предназначено, для отладки любое MPU подойдет.

Ну как это ничего ?? LWIP работает, таймеры все работают....UART который весит на USB работает...
Не работает только прерывание UART который весит на 485-м интерфейсе....

Сообщение отредактировал asm_lock - Mar 30 2016, 15:48

[ataradov]

Не работает только прерывание UART который весит на 485-м интерфейсе....

Ну так что говорит бит в регистре разрешения прерываний?

Гадать на кофе тут не выйдет, нужно отлаживать.

[AlexandrY]

Ну как это ничего ?? LWIP работает, таймеры все работают....UART который весит на USB работает...
Не работает только прерывание UART который весит на 485-м интерфейсе....

С LwIP так понимаю работаете из под FreeRTOS и все взято из примеров которые идут с SDK?
Судя по тому что в SDK нет примеров LwIP совместно с USB, то вы наверно совершили рискованное скрещивание.

[asm_lock]

С LwIP так понимаю работаете из под FreeRTOS и все взято из примеров которые идут с SDK?
Судя по тому что в SDK нет примеров LwIP совместно с USB, то вы наверно совершили рискованное скрещивание.

Никакого FreeRTOS'а нету... у Frescale примеры есть в KSDK_1.0.0

[AlexandrY]

Никакого FreeRTOS'а нету... у Frescale примеры есть в KSDK_1.0.0

Староватый SDK.
Теперь 2.0 актуальный и поддерживаемый.
Но кто мешает взять там пример под IAR и отлаживать с нормальным перехватом обращений к регистрам?

[asm_lock]

Ну так что говорит бит в регистре разрешения прерываний?

Гадать на кофе тут не выйдет, нужно отлаживать.

В осовном цикле UART3_C2 = 0x2C;
В обработчике UART3_C2 = 0x8C;

[AlexandrY]

В осовном цикле UART3_C2 = 0x2C;
В обработчике UART3_C2 = 0x8C;

TIE зависит от наличия процесса передачи и может быть любой и в обработчике и в цикле.
RIE должен быть всегда установлен.
Однако при переполнении прием запрещается. RIE устанавливается в 0, так написано в драйвере fsl_uart_driver.c
Поэтому проверьте переполнение.

[asm_lock]

TIE зависит от наличия процесса передачи и может быть любой и в обработчике и в цикле.
RIE должен быть всегда установлен.
Однако при переполнении прием запрещается. RIE устанавливается в 0, так написано в драйвере fsl_uart_driver.c
Поэтому проверьте переполнение.

В самом начале обработчика прерывания стоит опрос функции UART_HAL_GetRxDataRegFullIntCmd(baseAddr).
Когда перестаю приниматься данные , он всегда false .
Как это переполнение очистить то ?

Сообщение отредактировал asm_lock - Mar 31 2016, 09:24

[AlexandrY]

В самом начале обработчика прерывания стоит опрос функции UART_HAL_GetRxDataRegFullIntCmd(baseAddr).
Когда перестаю приниматься данные , он всегда false .
Как это переполнение очистить то ?

Так эта функция всего лишь возвращает значение RIE.
В новом SDK от нее уже отказались.
Поставьте просто

Код

UART3_C2 |= 0x20;

после этой функции.
Но будьте готовы к потере данных.

[asm_lock]

Код

UART3_C2 |= 0x20;

после этой функции.
Но будьте готовы к потере данных.

попробую...

ЗЫ: не помогло...

Сообщение отредактировал asm_lock - Mar 31 2016, 11:28

[AlexandrY]

попробую...

ЗЫ: не помогло...

А какая установка глубины FIFO стоит?

[asm_lock]

А какая установка глубины FIFO стоит?

Спасибо что спросили....
в инициализации только вот это прописано...

UART_HAL_SetRxFifoWatermark(baseAddr, 1);

/* Enable and flush the FIFO prior to enabling the TX/RX */
UART_HAL_SetTxFifoCmd(baseAddr, true);
UART_HAL_SetRxFifoCmd(baseAddr, true);
UART_HAL_FlushTxFifo(baseAddr);
UART_HAL_FlushRxFifo(baseAddr);

[asm_lock]

Увеличил размер FIFO в регистре UARTx_PFIFO до 64 слов....
И начал чистить его как только выползал флаг OR в регистре UARTx_S1.

Уже два часа работает без глюков...