[jcxz 184]

4 часа назад, MrBearManul сказал:

где-то я видел на форуме, что уважаемый @jcxz успешно пользовался RGU на этом микроконтроллере и сбрасывал периферию.

Вы что-то путаете.   Я с LPC4337 никогда не работал. Я работал с LPC4370.

На LPC4370 я использовал ADCHS и биты управления тактированием/сбросом его в RGU. Там с ними всё ок работает. Но я там использовал именно ADCHS, а не ADC (это разные, сильно различающиеся периферии; в LPC4370 насколько помню - есть и то и другое, в зависимости от корпуса).

 

PS: Глянул свой проект на LPC4370: Я сначала включаю тактирование для регистров периферии ADCHS со стороны ядра M4 (RGU), потом включаю тактирование самого ADCHS (RGU), потом подаю импульс сброса на ADCHS (RGU). И только после этих шагов начинаю работать с регистрами ADCHS.

Может у Вас не хватает каких-то действий?

[MrBearManul 0]

32 минуты назад, jcxz сказал:

Вы что-то путаете.   Я с LPC4337 никогда не работал. Я работал с LPC4370.

Простите, впредь буду внимательнее!

32 минуты назад, jcxz сказал:

PS: Глянул свой проект на LPC4370: Я сначала включаю тактирование для регистров периферии ADCHS

Я тоже подумал, что нужно включить тактирование. Но потом задумался, ведь системный RESET через RGU сбрасывает всю периферию, а там тактирование ещё не включено. Но завтра проверю на работе. Спасибо за подсказку!

 

 

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

Как вариант - может быть отключается источник тактирования ядра

Благодарю! И это завтра проверю!

33 минуты назад, jcxz сказал:

Может у Вас не хватает каких-то действий?

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

[jcxz 184]

3 часа назад, MrBearManul сказал:

Я тоже подумал, что нужно включить тактирование. Но потом задумался, ведь системный RESET через RGU сбрасывает всю периферию, а там тактирование ещё не включено. Но завтра проверю на работе. Спасибо за подсказку!

Я говорю о том, что в LPC4370 есть тактирование самой периферии (ADCHS) (1-й домен тактирования) и есть тактирование регистрового IO, через которое осуществляется управление этой периферией (2-й домен тактирования). Насколько помню - там некоторые периферийные блоки так организованы. Даже два набора сигналов тактирования регистрового IO: 1) для доступа со стороны ядра M4 (2-й домен тактирования); 2) и для доступа со стороны ядра M0 (3-й домен тактирования) - это разные сигналы разрешения тактирования регистрового IO.

И если Вы включили тактирование самой периферии, но не включили тактирование регистрового IO, а потом обращаетесь к этим регистрам, то это вполне может быть причиной зависания (ядро видимо входит в HALT, а эмулятор при этом отваливается).

Это только версия. Я работал с LPC4370 уже давно и вполне возможно что-то подзабыл и напутал - не буду утверждать.  

 

Цитата

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

см. выше. Ядро обращается к регистру IO, а он не затактирован -> ядро входит в бесконечный WAIT.

[MrBearManul 0]

23 минуты назад, jcxz сказал:

а потом обращаетесь к этим регистрам

Если вы подразумеваете регистры периферии, т.е. регистры управления АЦП 0 в моём случае, то к ним я точно не обращаюсь до включения тактирования. Примерно код выглядит так, извините, я не на рабте, поэтому напишу словами:

1. Сброс через RGU.

2. Инициализация АЦП (тактирование. разрядность, скорость и т.п.).

Так вот, если убрать п. 1, то всё работает прекрасно. В принципе, мне сброс не нужен. Но в ходе экспериментов, я его добавил и получил вот такой эффект. И меня это заинтересовало. Что инитересно, другая периферия успешно сбрасывается: последовательные порты, SPI и что-то ещё. Такой выкрутас пока только с АЦП0 и АЦП1 (не ADCHS, обычный ADC0/1).

[jcxz 184]

59 минут назад, MrBearManul сказал:

1. Сброс через RGU.

2. Инициализация АЦП (тактирование. разрядность, скорость и т.п.).

Так вот, если убрать п. 1, то всё работает прекрасно. В принципе, мне сброс не нужен. Но в ходе экспериментов, я его добавил и получил вот такой эффект. И меня это заинтересовало. Что инитересно, другая периферия успешно сбрасывается: последовательные порты, SPI и что-то ещё. Такой выкрутас пока только с АЦП0 и АЦП1 (не ADCHS, обычный ADC0/1).

А как вы подаёте сброс не включив тактирование?  Он у вас вообще по идее не должен работать, в этом месте должен зависнуть (при подаче сброса). Может Вы и сброс неправильно подаёте? 

И да - "такой выкрутас" потому что там два отдельных сигнала тактирования для разных целей (как я писал выше).

[MrBearManul 0]

16 часов назад, Edit2007 сказал:

Как вариант - может быть отключается источник тактирования ядра

Встал щупом на ножку XTAL2. До инициализации модуля генератора на ней какой-то постоянный уровень напряжения. После - меандр 12 МГц. Во время зависания ядра и до сброса сторожевым таймером эти импульсы не пропадают. Из этого я могу сделать вывод, что источник тактирования не отключается?

[MrBearManul 0]

9 часов назад, jcxz сказал:

И да - "такой выкрутас" потому что там два отдельных сигнала тактирования для разных целей (как я писал выше).

В общем проверил вашу гипотезу по-другому и грубо) Я закомментировал строку со сбросом АЦП через RGU. Програма запустилась, всё работает штатно. Далее, в отладчике, как и ранее предложил уважаемый @Arlleex, я снова вбил 0x100 в регистр RGU_RESET__CTRL1. Далее последовало зависание наглухо с отваливание J-Link.

 

После всего проверенного, честно говоря, начинаю теряться...

[jcxz 184]

7 часов назад, MrBearManul сказал:

Из этого я могу сделать вывод, что источник тактирования не отключается?

И что? А зачем бы он отключался?  

6 часов назад, MrBearManul сказал:

я снова вбил 0x100 в регистр RGU_RESET__CTRL1. Далее последовало зависание наглухо с отваливание J-Link.

Не понял - что именно Вы проверили и как это относится к тому, что я сказал?

Если следовать тому, что я сказал: да, при таком действии всё должно повиснуть. Но я вроде об этом и говорил.... несколько раз уже...  

[MrBearManul 0]

8 минут назад, jcxz сказал:

И что? А зачем бы он отключался?  

Я проверил гипотезу @Edit2007, где он предполагал, что источник выключатеся.

Ваши гипотезы пока проверяю.

 

Урезаю по-маленьку проет, чтобы понять, почему так происходит. Пока выходит, что если запустить планировщик у FreeRTOS, то при сбросе АЦП через RGU наблюдается данный феномен. Из-запущенных задач только IDLE.... Возможно, это хитрый глюк огромного сборого проекта, кой писали несколько человек.

 

Но мой самый главный вопрос теперь с ответом. Спасибо, уважаемый @jcxz! По-крайней мере теперь знаю, что если встанет ядро процессора, то и отладчик может отвалиться. До этого это мне было не совсем очевидно, я не изучал детально работу процессора и модуля CoreSight.

Изменено 15 января, 2021 пользователем MrBearManul

[jcxz 184]

Как сделано у меня (если поможет) на 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]

10 минут назад, jcxz сказал:

Как сделано у меня (если поможет) на LPC4370.

Спасибо, изучу!

10 минут назад, jcxz сказал:

При этом сигнал тактирования на АЦП уже подан?

Да, конечно! Но и более интересен следующий факт: если не запускать планировщик, а просто в main() войти в бесконечный цикл, то сброс АЦП происходит адекватно и без подачи частоты... Я пока стою на асфальте в лыжах... Не знаю, что там планировщик затрагивает кроме SysTick и настройки PendSV, SVC... Либо это ещё какой-то глюк, которого в упор не вижу. Мне дали доводить до ума проект с использованием старющей библиотеки CMSIS. Половина драйверов устройв на ней, половина - самописные... Ужас((())))

[jcxz 184]

3 минуты назад, MrBearManul сказал:

Мне дали доводить до ума проект с использованием старющей библиотеки CMSIS. Половина драйверов устройв на ней, половина - самописные... Ужас((())))

Понятно. Сочувствую. 

У меня там в приведённом фрагменте много участков с '///' - это у меня маркер говорящий "Внимание! На это нужно обратить внимание и переделать или удалить впоследствии, когда будет время!"

Обычно так я оформляю всякие отладочные вставки или участки, где не полностью разобрался и нужно впоследствии вернуться и внимательнее вникнуть (а пока нужно спешить идти вперёд).

Значит там у меня тоже что-то не получалось с 1-го раза, пилил. Но этот проект точно работает, так как есть. Просто он впоследствии "не взлетел" по иным причинам, поэтому так всё и осталось в таком состоянии - не доведённое до конца "до ума".  

А Вам - удачи в нелёгком деле разбирания в чужом коде!  

[MrBearManul 0]

3 минуты назад, jcxz сказал:

А Вам - удачи в нелёгком деле разбирания в чужом коде!  

Искренне спасибо)))