sergvks

Спасибо! Да всё так и есть, только в моём случае 1f, 2f т.к. у меня переходы вперёд.

Добрый день! При использовании директивы rept нельзя просто написать команду относительного условного перехода bne label, если label внутри клонируемого блока, т.к. ассемблер будет ругаться что метка уже определена. Как правильно тогда это оформить ?

Спасибо! Добавил .type и всё заработало.

Подскажите, как в GCC описать внешнюю асмовскую функцию размещенную в ram, чтобы он правильно оформил её вызов?

А сборку плат для РФ они случайно не возобновили ?

Есть ли в природе нечто похожее по функционалу на j-flash, но под CMSIS-DAP ?

Ещё одна деталь - в своих доках они рекомендуют размещать буферы dma в некешируемой части OCRAM, но в usb-шных примерах кладут их в DTCM. Если все буферы dma разместить в DTCM, чем это грозит ?

Прошу прощения, мой косяк - не туда глядел, реально не кеширует эти области. Спасибо за подсказки!

Если смотреть TCMCR,ВTCMCR и IOMUXC_GPR_GPR16 то биты Enable для TCM установлены, FlexRAM-контроллер тоже проинициализирован и если включен код настройки кеша из первого поста эти области памяти кешируются (видно при работе с DMA). Весь вопрос в чём тайный смысл кешировать то что и так работает на максимальной скорости.

По этим адресам находится ITCM и DTCM, у OCRAM другой адрес. Так вот не совсем понятно - достаточно ли того что память распределена по адресам ITCM и DTCM чтобы она работала как TCM или для этого нужно ещё что-то проинициализировать.

Во всех примерах на imxrt10хх так, конкретно этот код для mimxrt1052

Такой вопрос - зачем во всех примерах из sdk разрешается кеширование TCM ? /* Region 5 setting: Memory with Normal type, not shareable, outer/inner write back */ MPU->RBAR = ARM_MPU_RBAR(5, 0x00000000U); MPU->RASR = ARM_MPU_RASR(0, ARM_MPU_AP_FULL, 0, 0, 1, 1, 0, ARM_MPU_REGION_SIZE_128KB); /* Region 6 setting: Memory with Normal type, not shareable, outer/inner write back */ MPU->RBAR = ARM_MPU_RBAR(6, 0x20000000U); MPU->RASR = ARM_MPU_RASR(0, ARM_MPU_AP_FULL, 0, 0, 1, 1, 0, ARM_MPU_REGION_SIZE_128KB);

То что USB LDO проца +5 присутствует до подачи 3.3В нормально. Проблемы - медленное нарастание напряжения 5В от блока питания (большие емкости) и наличие входных уровней от внешних устройств на портах препятствовали нормальному запуску мк. Решение - супервизор 4.6В от входного 5В на Enable 3.3В стабилизатора процессора + супервизор 3В от стабилизатора процессора на Enable 3.3В стаба буферов портов. Пока буферы не запитаны их io в hz. По хорошему это всё нужно в мануале прописывать крупным шрифтом, 2 первых варианта собранных печаток ушли в корзину. При переходе с какого-нибудь STM32 эти вещи совсем не очевидны.

Я поступил немного по другому - супервизор 4.6В от входного 5В на Enable 3.3В стабилизатора, чтобы на проце раньше времени ничего не телепалось.

Кто-нибудь пробовал запитать ядро от линейного стаба ? Что-то в документации такого варианта я не нашел

Опять вопрос по диаметру падов, вот смотрю nxp'шные мк(imxrt1176) в bga с шагом 0.8мм - в их даташитах на корпуса рекомендованный диаметр падов 0.34мм, в их же эвалюшн бордах сделано 0.3мм, в посадочных местах из библиотек разного ПО может быть 0.37мм и кому верить ?

Пока думаю NC7SZ125 выглядит предпочтительнее. К сожаление сейчас нет под рукой этих или подобных буферов. Такой вопрос: а если взять 126 у которого вход OE неинверсный и закоротить OE c VCC, что будет у него на выходе при VCC=0, если на входе будет 3.3В ? Или стоит перестраховываться и брать 125 и супервизор с активхай ресетом на OE ?

У TXB0108 и аналогов максимальная пропускная частота 25МГц, а в моем случае внешний сигнал 100МГц. Все таки это больше преобразователь уровней, а нет ли других решений на случай когда уровни одинаковые, но нужно избежать утечку тока в незапитанный порт процессора ?

До появления напряжения питания портов мк нужно изолировать их от внешних сигналов - моем случае его частота 100МГц. Может чего посоветуете ?

Добрый день! Проблему удалось решить ? КМК путь один - ставить на порты с внешними устройствами буферы. Вот только вопрос какие ? Если исходить из этого:

Вид с другой стороны

MCUXpresso IDE LinkServer видит его как CMSIS-DAP probe, подключен к плате 3 проводами SWCLK, SWDIO, GND. Когда начал работать в MCUXpresso в наличии был отладчик встроенный в evkmimxrt1020 - очень медленный и китайский j-link v9 - постоянно вис при просмотре массивов от 1кб и более. Заказал с али несколько вариантов cmsis-dap с хай-спид юсб - в кейле они все работают без проблем, а вот с MCUXpresso завелся только один этот. Цена у всех примерно 1600р.

Может кому-то пригодится. Перепробовал несколько доступных девайсов китайских производителей, лучше всего себя показал - https://www.muselab-tech.com/daplinkgao-su-ban/ Работает очень шустро и на удивление вроде даже довольно стабильно.

Нужно оставить хотя бы 64к OCRAM для нормальной работы загрузчика:

Никто не знает где бы добыть Security Reference Manual for the i.MX RT102x и Processor Security Application Note AN12079 ?