[serwz 0]

Устройство на Sam7x256 в большой сетке периодически уходит в EMAC data abort.

Устанавливается бит SVMST_EMAC: Saved EMAC Abort Source, почему это случается

и как бороться, может кто сталкивался?

Как обрабатывать эту ситуацию ?

Если работать с устройством p2p, то работает днями без проблем.

[aaarrr 68]

почему это случается и как бороться, может кто сталкивался?

Потому что DMA EMAC'а из-за ошибки в драйвере неправильно обращается к памяти. В реальной сети это проявляется из-за большей загрузки.

[serwz 0]

Потому что DMA EMAC'а из-за ошибки в драйвере неправильно обращается к памяти. В реальной сети это проявляется из-за большей загрузки.

Под прием распределенно 200 блоков по 128 байт, битик в статусе приема BNA: Buffer Not Available не устанавливается, т.е. и драйвер и DMA работает.

Иногда устанавливается OVR: Receive Overrun, но как с этим бороться не знаю. Потому и прошу помощи - как эту ошибку обрабатывать?

Как сбрасывать этот data abort ?

[aaarrr 68]

Под прием распределенно 200 блоков по 128 байт, битик в статусе приема BNA: Buffer Not Available не устанавливается, т.е. и драйвер и DMA работает.

Что у Вас в MC_ASR (помимо SVMST_EMAC) и MC_AASR после аборта?

 

Иногда устанавливается OVR: Receive Overrun, но как с этим бороться не знаю. Потому и прошу помощи - как эту ошибку обрабатывать?

Никак не обрабатывать, просто принять к сведению - все сделает железка.

 

Как сбрасывать этот data abort ?

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

[serwz 0]

Что у Вас в MC_ASR (помимо SVMST_EMAC) и MC_AASR после аборта?

 

 

Никак не обрабатывать, просто принять к сведению - все сделает железка.

 

 

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

 

MC_ASR = 0х05010А01

 

MC_AASR - непонятный адрес, каждый раз меняется

 

Я понимаю что OVR: Receive Overrun все делает железка.

По поводу DataAbort

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

Как сбросить эту ситуацию - не знаю? Как сбросить DataAbort?

[xelax 0]

По поводу DataAbort

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

Как сбросить эту ситуацию - не знаю? Как сбросить DataAbort?

 

Наверное потомучто EMAC продолжает пытаться записать что-то по ошибочному адресу.

Дата аборт сбрасывается просто корректным выходом из обработчика

SUBS PC,R14_abt,#8

[aaarrr 68]

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

Как сбросить эту ситуацию - не знаю? Как сбросить DataAbort?

Естественно зацикливается - EMAC же продолжает ходить по левым адресам. Можно сбросить сам EMAC, но это не выход, так как нужно установить настоящую проблему.

 

Дата аборт сбрасывается просто корректным выходом из обработчика

SUBS PC,R14_abt,#8

Это если ядро вызвало исключение. Если виноват EMAC, то возвращаться нужно так:

SUBS PC, R14_abt, #4

О чем я, собственно, уже писал.

 

UPD: Хотя вопрос спорный - не понятно, что произойдет, если ядро не работало с памятью и получило abort или работало, но не являлось источником abort'а. Не стоит из него возвращаться, короче говоря.

[serwz 0]

Наверное потомучто EMAC продолжает пытаться записать что-то по ошибочному адресу.

Дата аборт сбрасывается просто корректным выходом из обработчика

SUBS PC,R14_abt,#8

 

Может вопрос в обработчике, примеров обработки этого исключения не нашел, ниже привожу текст

может в чем ошибка?

 

Data_Abort_Handler_Entry:

 

;-------------------------

;- Manage Exception Entry

;-------------------------

;- Adjust and save LR_irq in IRQ stack

sub lr, lr, #8

stmfd sp!, {lr}

 

;- Save r0 and SPSR (need to be saved for nested interrupt)

mrs r14, SPSR

stmfd sp!, {r0,r14}

 

;- Enable Interrupt and Switch in Supervisor Mode

msr CPSR_c, #SVC_MODE

 

;- Save scratch/used registers and LR in User Stack

stmfd sp!, { r1-r3, r12, r14}

 

;----------------------------------------------

;- Branch to the routine pointed by the AIC_IVR

;----------------------------------------------

b Data_handler

;----------------------------------------------

;- Manage Exception Exit

;----------------------------------------------

;- Restore scratch/used registers and LR from User Stack

ldmia sp!, { r1-r3, r12, r14}

 

;- Disable Interrupt and switch back in IRQ mode

msr CPSR_c, #I_BIT | IRQ_MODE

 

;- Mark the End of Interrupt on the AIC

ldr r14, =AT91C_BASE_AIC

str r14, [r14, #AIC_EOICR]

 

;- Restore SPSR_irq and r0 from IRQ stack

ldmia sp!, {r0,r14}

msr SPSR_cxsf, r14

 

;- Restore adjusted LR_irq from IRQ stack directly in the PC

ldmia sp!, {pc}^

 

 

Data_handler определяется в си файле

 

__arm void Data_handler(void)

{

EMAC_Init();

}

 

 

Все компилится в режиме генерации ARM кода

[aaarrr 68]

sub lr, lr, #8

stmfd sp!, {lr}

См. выше.

 

;- Mark the End of Interrupt on the AIC

ldr r14, =AT91C_BASE_AIC

str r14, [r14, #AIC_EOICR]

Это здесь зачем?

 

Не заморачивайтесь особо обработчиком - в нормальной ситуации Data Abort не должен возникать никогда.

[serwz 0]

См. выше.

 

 

Это здесь зачем?

 

Не заморачивайтесь особо обработчиком - в нормальной ситуации Data Abort не должен возникать никогда.

 

Спасибо за совет, но я пока не понимаю как я могу разрулить ситуацию с этим

Я DMA не управляю и шиной тоже и если возникает ошибка

 

• OVR: Receive Overrun

The DMA block was unable to store the receive frame to memory, either because the bus was not granted in time or

because a not OK hresp(bus error) was returned. The buffer is recovered if this happens.

 

то каким местом она может быть прицеплена к драйверу я затрудняюсь ответить.

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

 

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

Но могу ошибаться, с ядром АРМа знаком не досконально.

Если приведете пример обработчика - большое спасибо.

[aaarrr 68]

Ошибка OVR не связана с возникающим Data Abort.

 

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

Со стороны ядра - да, похоже на обычное прерывание. Но AIC к abort'ам никак не относится.

[serwz 0]

Ошибка OVR не связана с возникающим Data Abort.

 

 

Со стороны ядра - да, похоже на обычное прерывание. Но AIC к abort'ам никак не относится.

 

Ну тогда совсем не понятно, откуда берется признак EMAC abort, что причина?

драйвер только читает память контроллера и анализирует уже пришедшие пакеты, при чет тут EMAC data abort?

 

Ладно.

Спасибо за ответы, еще раз проверю драйвер.

[aaarrr 68]

Ну тогда совсем не понятно, откуда берется признак EMAC abort, что причина?

Например, грохнули дескрипторы DMA.

[defunct 0]

драйвер только читает память контроллера и анализирует уже пришедшие пакеты, при чет тут EMAC data abort?

Вот вопросы и ответы которые могут быть полезны, и которые Вы сами могли задать и ответить:

 

Это не драйвер аборт вызвал, а EMAC самолично.

Почему? - потому что ему сказали складывать или брать данные с неверного адреса.

Кто ему так сказал? - по всей видимости проц.

Где он так сказал? - да где угодно (например при формировании TX пакета) - вылезли за границу буфера - затерли шапку другого буфера, EMAC взял эту шапку - а там каша вместо верного адреса - вот и аборт.