jcxz 184 14 января, 2021 Опубликовано 14 января, 2021 · Жалоба 4 часа назад, MrBearManul сказал: где-то я видел на форуме, что уважаемый @jcxz успешно пользовался RGU на этом микроконтроллере и сбрасывал периферию. Вы что-то путаете. Я с LPC4337 никогда не работал. Я работал с LPC4370. На LPC4370 я использовал ADCHS и биты управления тактированием/сбросом его в RGU. Там с ними всё ок работает. Но я там использовал именно ADCHS, а не ADC (это разные, сильно различающиеся периферии; в LPC4370 насколько помню - есть и то и другое, в зависимости от корпуса). PS: Глянул свой проект на LPC4370: Я сначала включаю тактирование для регистров периферии ADCHS со стороны ядра M4 (RGU), потом включаю тактирование самого ADCHS (RGU), потом подаю импульс сброса на ADCHS (RGU). И только после этих шагов начинаю работать с регистрами ADCHS. Может у Вас не хватает каких-то действий? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
MrBearManul 0 14 января, 2021 Опубликовано 14 января, 2021 · Жалоба 32 минуты назад, jcxz сказал: Вы что-то путаете. Я с LPC4337 никогда не работал. Я работал с LPC4370. Простите, впредь буду внимательнее! 32 минуты назад, jcxz сказал: PS: Глянул свой проект на LPC4370: Я сначала включаю тактирование для регистров периферии ADCHS Я тоже подумал, что нужно включить тактирование. Но потом задумался, ведь системный RESET через RGU сбрасывает всю периферию, а там тактирование ещё не включено. Но завтра проверю на работе. Спасибо за подсказку! 2 часа назад, Edit2007 сказал: Как вариант - может быть отключается источник тактирования ядра Благодарю! И это завтра проверю! 33 минуты назад, jcxz сказал: Может у Вас не хватает каких-то действий? Тем не менее, вопрос, почему валится отладчик остаётся открытым. Что такого может произойти с ядром процессора? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 14 января, 2021 Опубликовано 14 января, 2021 · Жалоба 3 часа назад, MrBearManul сказал: Я тоже подумал, что нужно включить тактирование. Но потом задумался, ведь системный RESET через RGU сбрасывает всю периферию, а там тактирование ещё не включено. Но завтра проверю на работе. Спасибо за подсказку! Я говорю о том, что в LPC4370 есть тактирование самой периферии (ADCHS) (1-й домен тактирования) и есть тактирование регистрового IO, через которое осуществляется управление этой периферией (2-й домен тактирования). Насколько помню - там некоторые периферийные блоки так организованы. Даже два набора сигналов тактирования регистрового IO: 1) для доступа со стороны ядра M4 (2-й домен тактирования); 2) и для доступа со стороны ядра M0 (3-й домен тактирования) - это разные сигналы разрешения тактирования регистрового IO. И если Вы включили тактирование самой периферии, но не включили тактирование регистрового IO, а потом обращаетесь к этим регистрам, то это вполне может быть причиной зависания (ядро видимо входит в HALT, а эмулятор при этом отваливается). Это только версия. Я работал с LPC4370 уже давно и вполне возможно что-то подзабыл и напутал - не буду утверждать. Цитата Тем не менее, вопрос, почему валится отладчик остаётся открытым. Что такого может произойти с ядром процессора? см. выше. Ядро обращается к регистру IO, а он не затактирован -> ядро входит в бесконечный WAIT. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
MrBearManul 0 14 января, 2021 Опубликовано 14 января, 2021 · Жалоба 23 минуты назад, jcxz сказал: а потом обращаетесь к этим регистрам Если вы подразумеваете регистры периферии, т.е. регистры управления АЦП 0 в моём случае, то к ним я точно не обращаюсь до включения тактирования. Примерно код выглядит так, извините, я не на рабте, поэтому напишу словами: 1. Сброс через RGU. 2. Инициализация АЦП (тактирование. разрядность, скорость и т.п.). Так вот, если убрать п. 1, то всё работает прекрасно. В принципе, мне сброс не нужен. Но в ходе экспериментов, я его добавил и получил вот такой эффект. И меня это заинтересовало. Что инитересно, другая периферия успешно сбрасывается: последовательные порты, SPI и что-то ещё. Такой выкрутас пока только с АЦП0 и АЦП1 (не ADCHS, обычный ADC0/1). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 14 января, 2021 Опубликовано 14 января, 2021 · Жалоба 59 минут назад, MrBearManul сказал: 1. Сброс через RGU. 2. Инициализация АЦП (тактирование. разрядность, скорость и т.п.). Так вот, если убрать п. 1, то всё работает прекрасно. В принципе, мне сброс не нужен. Но в ходе экспериментов, я его добавил и получил вот такой эффект. И меня это заинтересовало. Что инитересно, другая периферия успешно сбрасывается: последовательные порты, SPI и что-то ещё. Такой выкрутас пока только с АЦП0 и АЦП1 (не ADCHS, обычный ADC0/1). А как вы подаёте сброс не включив тактирование? Он у вас вообще по идее не должен работать, в этом месте должен зависнуть (при подаче сброса). Может Вы и сброс неправильно подаёте? И да - "такой выкрутас" потому что там два отдельных сигнала тактирования для разных целей (как я писал выше). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
MrBearManul 0 15 января, 2021 Опубликовано 15 января, 2021 · Жалоба 16 часов назад, Edit2007 сказал: Как вариант - может быть отключается источник тактирования ядра Встал щупом на ножку XTAL2. До инициализации модуля генератора на ней какой-то постоянный уровень напряжения. После - меандр 12 МГц. Во время зависания ядра и до сброса сторожевым таймером эти импульсы не пропадают. Из этого я могу сделать вывод, что источник тактирования не отключается? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
MrBearManul 0 15 января, 2021 Опубликовано 15 января, 2021 · Жалоба 9 часов назад, jcxz сказал: И да - "такой выкрутас" потому что там два отдельных сигнала тактирования для разных целей (как я писал выше). В общем проверил вашу гипотезу по-другому и грубо) Я закомментировал строку со сбросом АЦП через RGU. Програма запустилась, всё работает штатно. Далее, в отладчике, как и ранее предложил уважаемый @Arlleex, я снова вбил 0x100 в регистр RGU_RESET__CTRL1. Далее последовало зависание наглухо с отваливание J-Link. После всего проверенного, честно говоря, начинаю теряться... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 15 января, 2021 Опубликовано 15 января, 2021 · Жалоба 7 часов назад, MrBearManul сказал: Из этого я могу сделать вывод, что источник тактирования не отключается? И что? А зачем бы он отключался? 6 часов назад, MrBearManul сказал: я снова вбил 0x100 в регистр RGU_RESET__CTRL1. Далее последовало зависание наглухо с отваливание J-Link. Не понял - что именно Вы проверили и как это относится к тому, что я сказал? Если следовать тому, что я сказал: да, при таком действии всё должно повиснуть. Но я вроде об этом и говорил.... несколько раз уже... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
MrBearManul 0 15 января, 2021 Опубликовано 15 января, 2021 (изменено) · Жалоба 8 минут назад, jcxz сказал: И что? А зачем бы он отключался? Я проверил гипотезу @Edit2007, где он предполагал, что источник выключатеся. Ваши гипотезы пока проверяю. Урезаю по-маленьку проет, чтобы понять, почему так происходит. Пока выходит, что если запустить планировщик у FreeRTOS, то при сбросе АЦП через RGU наблюдается данный феномен. Из-запущенных задач только IDLE.... Возможно, это хитрый глюк огромного сборого проекта, кой писали несколько человек. Но мой самый главный вопрос теперь с ответом. Спасибо, уважаемый @jcxz! По-крайней мере теперь знаю, что если встанет ядро процессора, то и отладчик может отвалиться. До этого это мне было не совсем очевидно, я не изучал детально работу процессора и модуля CoreSight. Изменено 15 января, 2021 пользователем MrBearManul Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 15 января, 2021 Опубликовано 15 января, 2021 · Жалоба Как сделано у меня (если поможет) на LPC4370. Инит ADCHS: Скрытый текст static void AdcOn() { u32 i, j; CGU.IDIV.B = PCLK_DIV - 1 << 2 | B11 | CLK_SRC_ID_PLL1 << 24; CGU.BASE.ADCHS = B11 | CLK_SRC_ID_IDIVB << 24; PeripheralOn(BRANCH_CLK_M4_ADCHS); //включение тактирования регистрового IO ADCHS PeripheralOn(BRANCH_CLK_ADCHS, RGU_RST_ADCHS); //включение тактирования ADCHS ADCHS.FIFO_CFG = B0 | 8 << 1; ADCHS.CONFIG = 1 | B5 | 0x90 << 6; ... enum { ... BRANCH_CLK_M4_ADCHS =0x073, //clock to the ADCHS. ... BRANCH_CLK_ADCHS =0x140, //ADCHS clock. }; enum { ... RGU_RST_ADCHS = 60 }; void PeripheralResetOn(RGU_RST periph) { if (periph == RGU_RST_none) return; __DMB(); /// *BITBAND_IO(&RGU.CTRL[periph >> 5], periph & B5 - 1) = 1; /// u64 q = 1ull << periph | 1ull << RGU_RST_M0APP | 1ull << RGU_RST_M0SUB; if (periph >> 5) q >>= 32; RGU.CTRL[periph >> 5] = q; } //Подаёт импульс RESET (или снимает постоянный RESET) на указанную периферию. //И включает её ветвь тактирования. Не конфигурит базовую частоту! void PeripheralOn(BRANCH_CLK branchClk, RGU_RST periphRst) { CCU_CFG_STAT volatile *p = &CCU1.BRANCH[0]; if (branchClk >> 9) p = &CCU2.BRANCH[0]; p += branchClk & B9 - 1; p->CFG = B0; while (!(p->STAT & B0)); if (periphRst == RGU_RST_none) return; PeripheralResetOn(periphRst); /// /// int i = 1; /// if (periphRst == RGU_RST_M0SUB || periphRst == RGU_RST_M0APP) i = 0; /// *BITBAND_IO(&RGU.CTRL[periphRst >> 5], periphRst & B5 - 1) = i; while (!*BITBAND_IO(&RGU.ACTIVE[periphRst >> 5], periphRst & B5 - 1)); __DMB(); } 14 минут назад, MrBearManul сказал: то при сбросе АЦП через RGU наблюдается данный феномен. При этом сигнал тактирования на АЦП уже подан? 17 минут назад, MrBearManul сказал: Возможно, это хитрый глюк огромного сборого проекта, кой писали несколько человек. Можно попробовать сделать это до старта ОС, в начале main(). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
MrBearManul 0 15 января, 2021 Опубликовано 15 января, 2021 · Жалоба 10 минут назад, jcxz сказал: Как сделано у меня (если поможет) на LPC4370. Спасибо, изучу! 10 минут назад, jcxz сказал: При этом сигнал тактирования на АЦП уже подан? Да, конечно! Но и более интересен следующий факт: если не запускать планировщик, а просто в main() войти в бесконечный цикл, то сброс АЦП происходит адекватно и без подачи частоты... Я пока стою на асфальте в лыжах... Не знаю, что там планировщик затрагивает кроме SysTick и настройки PendSV, SVC... Либо это ещё какой-то глюк, которого в упор не вижу. Мне дали доводить до ума проект с использованием старющей библиотеки CMSIS. Половина драйверов устройв на ней, половина - самописные... Ужас((()))) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 15 января, 2021 Опубликовано 15 января, 2021 · Жалоба 3 минуты назад, MrBearManul сказал: Мне дали доводить до ума проект с использованием старющей библиотеки CMSIS. Половина драйверов устройв на ней, половина - самописные... Ужас((()))) Понятно. Сочувствую. У меня там в приведённом фрагменте много участков с '///' - это у меня маркер говорящий "Внимание! На это нужно обратить внимание и переделать или удалить впоследствии, когда будет время!" Обычно так я оформляю всякие отладочные вставки или участки, где не полностью разобрался и нужно впоследствии вернуться и внимательнее вникнуть (а пока нужно спешить идти вперёд). Значит там у меня тоже что-то не получалось с 1-го раза, пилил. Но этот проект точно работает, так как есть. Просто он впоследствии "не взлетел" по иным причинам, поэтому так всё и осталось в таком состоянии - не доведённое до конца "до ума". А Вам - удачи в нелёгком деле разбирания в чужом коде! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
MrBearManul 0 15 января, 2021 Опубликовано 15 января, 2021 · Жалоба 3 минуты назад, jcxz сказал: А Вам - удачи в нелёгком деле разбирания в чужом коде! Искренне спасибо))) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться