[doom13 0]

С прерыванием от приёмника разобрался. При инициализации прерываний для каждого устройства выполнял IntAINTCInit() из либы TI

void IntAINTCInit(void)
{
    unsigned int cnt;
  
    /* Reset AINTC */
    for(cnt = 0; cnt < 3; cnt++)
    {
        HWREG(SOC_AINTC_0_REGS + AINTC_ECR(cnt)) = AINTC_ECR_DISABLE;
        HWREG(SOC_AINTC_0_REGS + AINTC_SECR(cnt)) = AINTC_SECR_ENBL_STATUS;
    }

    /* Disable FIQ and IRQ */
    HWREG(SOC_AINTC_0_REGS + AINTC_HIER) &= ~(AINTC_HIER_IRQ | AINTC_HIER_FIQ);

    /* Reset Global Interrupt register to disable global interrupt */
    HWREG(SOC_AINTC_0_REGS + AINTC_GER) = 0x0;

    /* Assign the ISR Table Address to VBR */
    HWREG(SOC_AINTC_0_REGS + AINTC_VBR) = (unsigned int)fnRAMVectors;

    /* Declare ISR Size (Function Pointer = 4 bytes) */
    HWREG(SOC_AINTC_0_REGS + AINTC_VSR) = 0x0;
}

 

и IntMasterIRQEnable(), IntGlobalEnable(), IntIRQEnable(). Счас сделал всю эту инициализацию один раз при старте программы - прерывание от приёмника заработало. Остался маленький вопрос по флагу RDATA, его сброс не оказывает никакого влияния на приём, что со сбросом, что без работает одинаково???

 

Вопрос с передатчиком - актуален!

 

 

С передатчиком вообще какая-то ерунда, записываю данные в XBUF(x), McASP сбрасывает флаги XDATA и XRDY и они больше не поднимаются. Не могу понять что же может быть причиной такой работы?

Приёмная часть тактируется в моём случае от передающей, т.е. раз там есть возможность правильного приёма, то тут передача должна работать.

 

[BratherLU 0]

С передатчиком проблема следующая

- достаточно возникнуть Tx buffer Underrun событию и автомат состояний передатчика встает колом.

Соответственно - лечение: не допускать underrun.

Возможные варианты:

1) Гарантированно успевать CPU писать данные в TX_BUFF(x) + включать AFIFO от mcasp

2) Использовать - EDMA+AFIFO от mcasp

3) Использовать PRUSS

 

TX AFIFO - лучше использовать даже при работе через EDMA. т.к. при определенном уровне нагрузки на EDMA связка может зависнуть. При этом ни в одной периферии ошибок не видно. Под нагрузкой имею ввиду например работу с MMCSD на том же контроллере.

 

На форуме TI есть пара тем по данному вопросу.

Как запустить AFIFO написано документации на MCASP

 

[doom13 0]

Вижу проблему немного в другом.

1) Передатчик молчит

1.1 Стоял запрет на все прерывания от передатчика в XINTCTL

1.2 Отправку данных пытался сделать следующим образом:

void McAsp::Send(unsigned char *data)
{
    unsigned int reg_data;
    unsigned int tx_data;

    tx_data = (unsigned int)*data;
             
    reg_data = HWREG(base_addr + MCASP_SRCTL(13));            // a)
    if(reg_data & MCASP_SRCTL13_XRDY)
    //reg_data = HWREG(SOC_MCASP_0_CTRL_REGS + MCASP_XSTAT);    // b)
    //if(reg_data & MCASP_XSTAT_XDATA)
    {
        HWREG(base_addr + MCASP_XBUF(13)) = tx_data;//(unsigned int)*data;
    }
}

, как результат: один раз записывало в XBUF, далее флаги постоянно в нуле и никакой передачи нет.

2) Передатчик начал передавать данные

2.1 Разрешил прерывание при освобождении XBUF и разрешении записи в него

HWREG(base_addr + MCASP_XINTCTL) = (1 << MCASP_XINTCTL_XDATA_SHIFT); //0;

2.2 Отправку данных перенёс в обработчик прерывания

void McAsp::Isr()
{
    reg_data = HWREG(SOC_MCASP_0_CTRL_REGS + MCASP_XSTAT);
    if(reg_data & MCASP_XSTAT_XDATA)
    {
        HWREG(SOC_MCASP_0_CTRL_REGS + MCASP_XBUF(13)) = 0xAAAAAAAA;
    }

    IntSystemStatusClear(SYS_INT_MCASPINT);
}

Второй вариант запустился, но не пойму, почему установка XDATA зависит от разрешения прерывания (возможно ещё что-то не вижу ошибочного в моих действиях).

[BratherLU 0]

О причинах не запуска передачи могу сказать что XDATA выставится сразу при отпускании автомата состояния сериалайзера - об этом в доке написано.

Вероятно первый вариант не запустился т.к. не известно когда вы вызвали Send() может уже underrun возник.

По прерыванию вы тут же влетели в обработчик все сработало штатным образом - я так думаю (с).

[doom13 0]

О причинах не запуска передачи могу сказать что XDATA выставится сразу при отпускании автомата состояния сериалайзера - об этом в доке написано.

Вероятно первый вариант не запустился т.к. не известно когда вы вызвали Send() может уже underrun возник.

С передатчиком проблема следующая

- достаточно возникнуть Tx buffer Underrun событию и автомат состояний передатчика встает колом.

Тогда здесь поясните пожалуйста, т.е. если мне не надо ничего передавать в данный момент, но я настраиваю для передатчика разрешение передачи в одном из таймслотов (иногда буду выставлять данные), то при появлении нового фрейма и пустом XBUF (я не хотел ещё ничего передавать) - произойдёт UNDERRUN (прочитается пустой XBUF и что-то полюбому отправится)??? Правильно ли я понимаю?

Если включаю передатчик, то это обязывает меня каждый новый фрейм выставлять данные в разрешённые таймслоты?

[BratherLU 0]

Да. Вы обязаны писать в XBUFF(x) в каждом активном таймслоте для каждого активного передатчика поосле запуска передатчика

[doom13 0]

Да. Вы обязаны писать в XBUFF(x) в каждом активном таймслоте для каждого активного передатчика поосле запуска передатчика

Тогда это объясняет, почему передача работает из обработчика прерывания, а если делать пулом, то не работает, спасибо. Вообще передатчик мне нужен только при старте прцессора, для конфигурации модема, далее только приёмник будет работать.

Ещё замечено, что после запуска приёмника/передатчика какое-то время всё работает, потом может произойти какой-то сбой (нет ни передачи ни приёма), постоит подумает, может опять запуститься. Не знаю, похоже, что вдруг тактирование отвалилось или что-то вроде этого, на осциллографе всё нормально (пропадания тактирующей частоты нет). Правда, есть какая-то асинхронность клока относительно фрэйма, но McBSP c такой аномалией нормально работал, может ли это быть причиной остановки в работе McASP (через какой-то промежуток времени опять всё заводится).

[BratherLU 0]

В Mcasp есть регистры RCLKCHK/XCLCHK - можно их использовать для диагнотики проблем с пропажей аппаратной синхронизации. Прием поднимется после восстановления синхронизации; передача скорее всего нет (не уверен на счет передачи) - может потребоваться перезапуск передатчика.

[doom13 0]

В Mcasp есть регистры RCLKCHK/XCLCHK - можно их использовать для диагнотики проблем с пропажей аппаратной синхронизации. Прием поднимется после восстановления синхронизации; передача скорее всего нет (не уверен на счет передачи) - может потребоваться перезапуск передатчика.

Смотрел на эти регистры, но не понял, как они используются, если можно, поясните пожалуйста.

А ещё меня смущает, что для ST-BUS в моём случае модем выдаёт удвоенную частоту (на каждый бит данных приходится по два такта тактирующей частоты), использую при приёме McASP данную частоту делённую на два и синхронизацию от модема (длительность синхроимпульса один такт исходной частоты). Нормально ли McASP будет воспринимать длительность фреймового импульса в половину периода частоты на которой он сам работает (если проводить сравнение с работой McBSP, то там нет таких проблем, а системы ведь похожи)???

Ещё интересует вопрос, если McASP тактируется с использованием своего внутреннего делителя, есть ли какой-то сброс данного делителя при поступлении нового фреймового синхроимпульса, или же после старта клоки формируются далее непрерывно?

[jcxz 184]

Ещё интересует вопрос, если McASP тактируется с использованием своего внутреннего делителя, есть ли какой-то сброс данного делителя при поступлении нового фреймового синхроимпульса, или же после старта клоки формируются далее непрерывно?

Сброс чего?

В McASP (насколько я помню) генератор клоков и генератор фреймов - разные генераторы. Я кстати в своих исходниках именно поэтому и запускаю их по отдельности: сперва - клоки, потом - фреймы.

Но у меня источник фреймов - McASP, а у вас как я понял - они приходят извне.

Но даже в этом случае отсутствие или наличие фреймового импульса не должно влиять на клоки (XCLK/RCLK) - они всё равно будут также идти.

А вот что будет с обработкой фрейма если фреймовый импульс придёт не через заданное кол-во тактов, а раньше или позже - надо смотреть даташит.

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

 

Также меня берут большие сомнения насчёт фреймового импульса длительностью менее одного периода XCLK/RCLK. Даже в случае если источник фреймов - McASP,

то минимальная длительность фрейма == 1период. А если они внешние, то регистрация фреймовых импульсов скорей всего синхронная

(по фронту или спаду CLK или HCLK). А скорей всего она идёт по CLK, а не по HCLK. А значит для гарантированной регистрации начала фрейма - фреймовый импульс должен быть заведомого больше периода CLK (с запасом).

Вам надо или расширить этот импульс внешней схемой.

Или попробовать подвигать его фазу относительно CLK от модема (например - инвертором или какой-либо схемой задержки). Раз модем является источником

и HCLK и фреймового импульса, значит они должны быть связаны друг с другом по фазе и можно найти такую величину сдвига, при которой точка

регистрации фрейма внутри McASP будет зведомо попадать внутрь этого принимаемого фреймового импульса.

[doom13 0]

Сброс чего?

В McASP (насколько я помню) генератор клоков и генератор фреймов - разные генераторы. Я кстати в своих исходниках именно поэтому и запускаю их по отдельности: сперва - клоки, потом - фреймы.

Тут имелось ввиду что-то типа перезапуска генератора клоков с приходом нового фрейма, т.е. чтобы фаза клока относительно начала фрейма поддерживалась постоянной. Не верно посчитал длительность фрейма, добавил к количеству клоков для слотов ещё один на синхроимпульс, получил 513 и решил, что в этом случае начальная фаза клока будет прыгать. Модем выдаёт 32 слота по 8 бит и по 2 клока на 1 бит. Итого получаем длительность фрейма 32 х 8 х 2 = 512 клоков. Не понятно, как это всё будет работать с клоком делённым на 2 (опять же, для McBSP всё классно работает и нет каких-либо сбоев), если длительность фреймового импульса 1 такт исходной частоты.

 

Но у меня источник фреймов - McASP, а у вас как я понял - они приходят извне.

Но даже в этом случае отсутствие или наличие фреймового импульса не должно влиять на клоки (XCLK/RCLK) - они всё равно будут также идти.

Да, фрейм использую внешний. Из всех слотов приходящего фрейма интересны только первых 4, далее можно всё отбросить и не рассматривать. Не понятно, почему может происходить остановка приёма данных, почему для McBSP такого не наблюдалось, та же система с менее гибкими настройками и возможностями.

Возможно ли внутри McASP растянуть длительность фрейма на два такта исходной частоты (такт RCLK, XCLK)?

 

А вот что будет с обработкой фрейма если фреймовый импульс придёт не через заданное кол-во тактов, а раньше или позже - надо смотреть даташит.

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

Там есть режим Burst Mode, где возможен приём нескольких слотов в начале фрейма, всё остальное можно отбросить (по даташиту так описано), но что-то в моём случае это не помогло, надо будет попробовать ещё его потестить, но вопрос начальной фазы клока для приходящего фрейма опять остаётся открытым.

 

Также меня берут большие сомнения насчёт фреймового импульса длительностью менее одного периода XCLK/RCLK. Даже в случае если источник фреймов - McASP,

то минимальная длительность фрейма == 1период. А если они внешние, то регистрация фреймовых импульсов скорей всего синхронная

(по фронту или спаду CLK или HCLK). А скорей всего она идёт по CLK, а не по HCLK. А значит для гарантированной регистрации начала фрейма - фреймовый импульс должен быть заведомого больше периода CLK (с запасом).

Вам надо или расширить этот импульс внешней схемой.

Или попробовать подвигать его фазу относительно CLK от модема (например - инвертором или какой-либо схемой задержки). Раз модем является источником

и HCLK и фреймового импульса, значит они должны быть связаны друг с другом по фазе и можно найти такую величину сдвига, при которой точка

регистрации фрейма внутри McASP будет зведомо попадать внутрь этого принимаемого фреймового импульса.

Если регистрация фреймовыж импульсов синхронная, то и получается ерунда какая-то, и не должно работать?! Не сможем задетектировать фреймовый импульс?! Опять же вопрос, каким образом McBSP работает в аналогичной ситуации???

 

Похоже, нашёл разницу в работе McBSP и McASP. Предположительно McBSP может работать т.к. и фрейм и клоки формируются внутренним генератором McBSP на основе внешнего битового клока (удвоенного) и фреймового импульса длительностью в один клок (см. рисунок).

Что скажете по этому поводу? Правильны ли мои рассуждения?

 

И ещё кусок даташита к рисунку

When the external clock (CLKS) is selected to drive the sample rate generator (CLKSM = 0 in SRGR and

SCLKME = 0 in PCR), the GSYNC bit in SRGR can be used to configure the timing of CLKG relative to

CLKS. GSYNC = 1 ensures that the McBSP and the external device to which it is communicating are

dividing down the CLKS with the same phase relationship. If GSYNC = 0, this feature is disabled and

CLKG runs freely and is not resynchronized. If GSYNC = 1, an inactive-to-active transition on FSR triggers

a resynchronization of CLKG and the generation of FSG. CLKG always begins at a high state after

synchronization. Also, FSR is always detected at the same edge of CLKS that generates CLKG,

regardless of the length the FSR pulse. Although an external FSR is provided, FSG can still drive internal

receive frame synchronization when GSYNC = 1. When GSYNC = 1, FPER does not matter, because the

frame period is determined by the arrival of the external frame sync pulse.

[jcxz 184]

Если регистрация фреймовыж импульсов синхронная, то и получается ерунда какая-то, и не должно работать?! Не сможем задетектировать фреймовый импульс?! Опять же вопрос, каким образом McBSP работает в аналогичной ситуации???

Похоже, нашёл разницу в работе McBSP и McASP. Предположительно McBSP может работать т.к. и фрейм и клоки формируются внутренним генератором McBSP на основе внешнего битового клока (удвоенного) и фреймового импульса длительностью в один клок (см. рисунок).

Что скажете по этому поводу? Правильны ли мои рассуждения?

Не знаю как там в McBSP, но думаю, что примерно так же.

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

Соответственно - длительность внешнего фреймового импульса должна быть заведомо больше периода CLK, чтобы регистрация фреймового импульса могла происходить

при любом сдвиге фазы FSX/FSR отнсительно CLK.

[doom13 0]

Не знаю как там в McBSP, но думаю, что примерно так же.

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

Соответственно - длительность внешнего фреймового импульса должна быть заведомо больше периода CLK, чтобы регистрация фреймового импульса могла происходить

при любом сдвиге фазы FSX/FSR отнсительно CLK.

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

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

Обрадовало то, что McASP всё же работает со стабильным приёмом, но счас надо программно корректировать принимаемые данные, т.е. принимать будем 16-бит для слота вместо 8-ми, где каждые два одинаковы.

Что-то читал про маску для определённых бит и padding, но пока не разобрался, подходит ли оно мне? Может быть есть возможность для McASP настроить приём бит через один?

[BratherLU 0]

Что-то читал про маску для определённых бит и padding, но пока не разобрался, подходит ли оно мне? Может быть есть возможность для McASP настроить приём бит через один?

А может лучше завести битовую синхронизацию на АHCLKR потом поделить внутренним делителем MCASP и от этих клоков засинхронизировать прием. AHCLKR/H можно даже внутри проинвертировать - в MCASP есть все тоже самое что и в MCBSP (кроме g711)

[doom13 0]

А может лучше завести битовую синхронизацию на АHCLKR потом поделить внутренним делителем MCASP и от этих клоков засинхронизировать прием. AHCLKR/H можно даже внутри проинвертировать - в MCASP есть все тоже самое что и в MCBSP (кроме g711)

Оно так и сделано, только заведено на AHCLKX (выше схему выкладывал), но возникла проблемка с синхронизацией (описывается примерно с начала данной страницы), поэтому и ищу способ, как лучше отформатировать принимаемые данные.