jcxz

Однозначно - в проекте. Если не хватает памяти, проект не должен собираться.

Ужас просто.... К чему приводит нежелание учить матчасть и упорное пользование всякими либами.... :smile3046: На вышеозначенном проце данные операции (и disable и clearpending) выполняются всего по две пары записей в регистры NVIC.

По-моему - проблема выеденного яйца не стоит. Если при завершении передачи (нет больше данных для передачи) в ISR вы маскируете THRE, то потом, когда фоновая задача хочет записать новые даные для передачи, она делает следующее: 1. мьютекс/запрет прерываний. 2. проверка - THRE замаскировано(запрещено)? нет - переход к 5. 3. размаскируем THRE 4. заполняем TX fifo. 5. освобождение мьютекса/разрешение прерываний. Если при завершении передачи (нет больше данных для передачи) в ISR вы не маскируете THRE, а просто выходите из ISR (предварительно сбросив программный флаг "TX в процессе"), то потом, когда фоновая задача хочет записать новые даные для передачи, она делает следующее: 1. мьютекс/запрет прерываний. 2. проверяете флаг "TX в процессе". Если стоит - переход к 5. 3. уставливаем флаг "TX в процессе" 4. заполняем TX fifo. 5. освобождение мьютекса/разрешение прерываний.

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

Если бы Вы хотя-бы открыли ту тему прежде чем отвечать, Вы бы заметили, что я цеплял там полностью проект. Это понятно. Но хочется работать без гемора с постоянным переключением между компиляторами.....

Если кто отправлять будет, то напишите до кучи и про мой баг (писал о нём недавно сюда: http://electronix.ru/forum/index.php?showtopic=105402 ) Вдруг - поправят? ;) А то сейчас по необходимости пользую IAR 6.21.1 (старый 5.50 который хорошо проверен на вшивость большими проектами с полной оптимизацией, но к сожалению 5.50 не понимает через JTAG LPC1778) :(( И поэтому приходится ставить Low оптимизацию в 6.21.1. ЗЫ: Проверил примеры из этой темы на своём IAR 6.21.1 - бага нет (ни с чётными ни с нечётными размерами циклов). Cortex-M3 High optimization (Size)

Им можно только посочувствовать.... :crying: Один уже похоже отправился проводить опытную эксплуатацию собственной разработки лично на лесоповал

Отсюда - можно подробнее, что за задержки? Сколько работаю с USB вроде ни разу не сталкивался.... Ядро C5000 на порядок лучше любого Cortex-а на сравнимой частоте для сигнальной обработки. Но человек боится этого страшного слова DSP!..... :) И на отладочные платы указали дешёвые, а всё равно - будет что-то паять на коленке заведомо гораздо худшее и по разрядности АЦП/ЦАП и по возможностям обработки и ещё и без JTAG - будет долго возиться с кодом..... кустарщина вобщем ;)

Получается что FIQ вам не нужен. Зачем тогда его используете? Сделайте все прерывания через IRQ. И обнулять в обработчике ничего не нужно. Почитайте мануал на ядро про режимы процессора. Найдите где у вас в начале программы выставляются дефолтные значения для флагов CPSR для режимов FIQ и IRQ и выставьте их там.

Так-ли? К примеру в даташите на F28M35 вроде написано, что можно заблокировать JTAG (см. раздел "JTAG Lock"). На ARM-ах NXP к примеру тоже можно заблокировать. Например в ARM-ах NXP если флешь заблокирована и считать/записать её нельзя и JTAG заблокирован, то можно только выполнить полное стирание флешь (через UART), после этого и защита тоже сбрасывается.

С чего бы это PLC стал мёртвым?

Как же не надо? Любой OMAP - это два ядра, между которыми надо осуществлять обмен данными.

Какой эмулятор?

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

Нее - о программной эмуляции DMA

Ну и что? Это не говорит о том, что производитель не тестирует свои процы. Вероятность того, что вы обнаружите баг проца в мэйн-стрим компонентах (типа i2c или UART которые использует большинство разработчиков) при стандартном использовании этих компонентов, стремится к нулю. Ищите баги в первую очередь у себя... И во-вторую тож. Мы вот тож делаем разработку на совершенно новом LPC1778 и пока багов в железе не обнаружили ни в i2c ни в SPI ни в UART, DMA, GPIO, CRC, таймерах.... Ужас просто. Даже аппаратный i2c очень неудобная вещь (по-крайней мере в тех процах, что я имел дело) в плане паразитной загрузки процессора - прерывание на каждый байт, отсутствует DMA и даже FIFO. В моих проектах наибольшую частоту всегда имеет прерывание i2c - в остальных интерфейсах частоту прерываний можно снизить за счёт DMA или FIFO. А большая частота прерываний выливается в непроизводительную загрузку CPU на входы/выходы в ISR (особенно при наличии ОСРВ). А вы его хотите еще программно делать.... Ну конечно если у вас процессору больше нечем заниматься, то пофиг.

Что-то у вас всё программно - и i2c и 1-wire и даже UART.... Может полезней будет научиться читать доки на процессоры? ;)

Да уж, нагородили ... техасцы на ровном месте..... Думаю, что у L138 тогда более логичный порядок старта. Всегда удивляло - зачем в L137 сделали главным в запуске DSP? Кстати - не единственное - для нас существенным доводом в пользу L137 против L138 стало наличие в первом McASP (в L138 - только McBSP).

Значит - всё точно так же как в L137. А зачем Вы отрубаете DSP после старта ARM? Если интересно могу привести свой код, которым запускаю ARM (см. прикреплённый файл).boot.zip Файл boot.asm (который в составе rts.lib) модифицирован как указано в моём посте выше. Начало main() из DSP-проекта: #pragma FUNC_NEVER_RETURNS int main() { u32 cpuUseIdle; s32 i; CACHE.L1DCFG = 7; i = CACHE.L1DCFG; soc.faza = soc.FAZA_BEGIN; EnableARM(); CooperateWait(soc.FAZA_DSPIDLE_MEAS); //отсель ARM и DSP работают совместно ...

Почему тогда всё прекрасно работает (на любых частотах вплоть до максимальных) если нет перекрытия по времени работы двух SSP? Проверил несколько миллионов транзакций. При перекрытии и частотах выше какого-то порога (15/12МГц или 20/6МГц) сбой появляется уже в первой тысяче транзакций.

Да, согласен с Вами. Сейчас у меня так и сделано. Всё - разобрался в проблеме. Баг был у меня ;) Когда копировал функцию запуска DMA-транзакции одного SSP и переделывал её для другого SSP, забыл для второго SSP сделать свои объекты для LLI структур (у меня передачи связными списками), соответственно они и портились :) После этого заработало всё, но на маленькой скорости. Для работы на полных 30МГц по одному SSP и 20МГц по другому SSP, пришлось отказаться от автоматического управления линией SSEL - похоже шина не успевала прокачивать данные для TX-канала и SSEL кратковременно обрывался (вследствие чего проходил сбой операции у DFLASH/FRAM микросхемы). Хотя для GPDMA-контроллера выставил максимальный приоритет доступа к шине в регистре арбитража AHB (выше чем у CPU) - это не помогало. Уже всё пашет - тест показывает 3.5млн транзакций по одному SSP и почти миллион по другому. С перекрытием. :)

Похоже рано радовался :((( Вышеописанная проблема решилась, но всё равно перекрывающиеся DMA-транзакции работают нестабильно (если два SSP-канала работают по GPDMA). В какой-то момент времени при очередном наложении транзакций с двух SSP происходит сбой. Выражается это в порче передаваемых данных. Т.е. - читаю блоки данных по двум SSP с перекрытием по времени и в какой-то момент времени в одной из транзакций получаю искажённые данные, причём после этого не приходит прерывание завершения по более низкоприоритетному из работающих DMA-каналов. Такое ощущение, что более приоритетный DMA-канал перехватывает запрос от низкоприоритетного DMA-канала (от другого SSP) и выполняет его, передавая или принимая данные к чужому или от чужого SSP. Бред полный..... Кто-нить вообще работал на LPC17xx с перекрывающимися по времени GPDMA-транзакциями работающими с разной периферией? Именно _с_разной_, 2 DMA-канала для одного SSP (ввод/вывод) работают прекрасно. А вот когда их уже 4...... Перепробовал уже всё что возможно (частоты SSP, распределение GPDMA-каналов, управление SSEL(GPIO и автомат) и т.п.). И еррата молчит

Хм... А что - в L138 первым стартует ARM? Работал с L137 только - там стартует DSP (по вкл. питания ARM - в ресете) , код bootloader-а выполняет DSP, и в пользовательском ПО чтобы использовать ARM, надо сперва прописать таблицу векторов для ARM (в его памяти), а потом - включить его и вывести из ресета. Под JTAG - на L137 доступны сразу оба ядра, так как JTAG их сам выводит из ресета когда подключается к ним. И на отладку под JTAG можно запускать сразу два проекта параллельно. rts.lib файл boot.asm:cstartup: .asmfunc MRS R0, SPSR ;Now will ORR R0, R0, #CPU_MODE_SYS;set to SVC mode MSR CPSR, R0 ; with privileges Можно конечно через SWI. Но я делаю как показал выше - так проще. Кроме того - в этом rts.lib можно ещё что-нить пооптимизить и пообкусывать.

Вот потому и спрашивал - на ARM7/ARM9 выход из ISR отличается от выхода из обычной функции необходимостью копирования SPSR в CPSR (в которых и хранится режим процессора). Когда вы определили функцию как interrupt("FIQ"), то соответственно изменились команды восстановления контекста по выходу.

А как выходите из ISR?