решил портировать FatFS (tiny FatFS) на SAM7
прожект в ИАРе.
SPI настроил, с флэшкой проц говорить научил.
но при выполнении внутренней команды auto_mount на строке

basesect = LD_DWORD(&fs->win[MBR_Table+8]); /* Partition offset in LBA */

LD_DWORD определен (если упрощать) как разименование указателя , приведенного к типу указатель на беззнаковое длинное.

в дебаггере в асме выглядит как четыре строки :
MOV R0,#245
LSL R0,R0,#1
LDR R0,[R4,R0] // ПРИ ВЫПОЛНЕНИИ ЭТОЙ КОМАНДЫ ПРЫГАЕТ НА DATA ABORT
LSL R7,R0,0#

в чем может быть дело?

В невыровненых указателях. Обращение к слову должно быть выровнено на границу 2 байт, к двойному слову на 4. Вы же обращаетесь (похоже) к нечетному элементу массива char'ов, как к слову. Соответственно по нечетному адрессу.

А помоему в R4 (&fs) лежит мура какая-то. Неприпоминаю, чтобы простенькие 7-ые армы генерировали abort при data missalign

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

А что еще они должны делать? И причем здесь простенькие-непростенькие?

А ничего - просто обрезают младшие биты. NXP так делает.
Автор - подробнее про endian - что у Вас было в R4 при этом ?

генерят , и какая бы там мура не лежала ,если она попадает на кратную позицию - то аборта нет



нечетное число

значит это SAM7 такое делает. LPC - не делали, если мне склероз не изменяет.

Гы.
Ну могу сказать что на sam data abort при невыровненности вполне себе работает. Недавно возился со упакованной структурой на асме.

Торможу короче - SAM дает аборт при ЧТЕНИИ по невыровненному указателю ? Крута.

ARM7 дает data abort при любом доступе к памяти при невыровненом указателе.
SAM7 и LPC2xxx включительно.

Зачем фантазировать ? LPC2148

volatile int testVar;
int *ptestVar;
ptestVar = (int*)0x1;
testVar = *ptestVar; // проходит без вопросов. Результат как если бы указатель был равен 0
Это проверено реально. А у Вас реальная инфрмация или процесс творческого переосмысления даташитов на ядро ?

На LPC2214 у меня не проходило.

Тогда это очень интересная тема, которую надо развить - столь серъеное различие в ядрах 2214 и 2148

Жжоте! хотите сказать у них ядра по-разному работать ухитряются?
Вообще abort при messaligment относится ко всей архитектуре arm, на сколько я понимаю. И то что lpc при каких-то обстоятельсявах работает не может не радовать.

Люди, вы реальность то проверьте... Говорю же - не дает аборта, и при записи тоже не дает (если адрес в ОЗУ). Просто свернет младшие биты и все

Ну нет у меня филипса. Дотянусь если до 2103 после праздников обязательно проверю. Но это странно по меньшей мере. Может это компилер такой хитрый а?

Какой компилер ??? LDR R0, [R5]
R5 равно 1

Вообще-то это не совсем корректно. Нужно смотреть на дизфссемблер этого куска. Это будет зависеть от компилятора.
gcc 3.3.6 дает типа
mov r1, #1
ldr r0, [r1] <- Data Abort
А если компилятор выполит проверку выравнивания и сброс младших бит по маске, то будет типа
mov r1, #0 <- Как результат компилляции
ldr r0, [r1]

Ну замужем не первый год - конечно по асму говорю

Ясно.
А может ктони-ть проверит еще на филипсе? Может у них действительно ядра разные? Ну или филипс его доработал слегка для некоторых камней? ))

Надпись на чипе:
LPC2214FBD144
CD8986 01
S60535A

Компилирую асм файл.
Перед этим выполнен remap - Адрес 0 -> ОЗУ.
Включен MAM по полной программе.


Дает data abort.

Дает data abort.

DASM
А у Вас этот камень ввобще в data abort когда-нить входит?

Ну а в 2148 никаких абортов ни при каком MEMMAP

Поправка:

Надпись на камне не очень четкая, вот это
S60535A
похоже на
TS60535A
и на
TSG0535A

Конечно входит. Если MEMMAP оставить на флеше, то при записи по 1 - получу ABORT. Впрочем как и по нулю конечно. А При ОЗУшном расположении - все нормально, и на чтении и на записи по невыровненному

Единственная мысль - контроллер памяти у 2214 несколько иной - она же с внешней шиной ? Или нет ?

Как в том анегдоте.
"Это не ежик. Это фигня какая-то."

У кого есть филипс, проверте плз!!!


Да.
Но, описываемое Вами поведение противоречит ARM7TDMI. Тогда это бага филипса.
Или фича

Про фичу - вполне возможно. Я тут наткнулся где-то на статейку, где было написано: во многих нынешних реализациях ARM ядер возможность чтения с невыравненных адресов решена аппаратно. К сожалению не помню адрес и реквизиты источника. Но неужели если NXPэто реализовал, в документации не отразил тогда этот радостный факт? Это странно.

Чего решена ? Куда решена ? Считывает то NXP - некорректно. То есть нафик-нафик такая фича нужна, я лучше бы такие промахи через abort отслеживал

А есть ли в природе или может у кого порт данной FS для nxp?

Последняя версия работает без всякого портирования. Для ARM надо указать _MCU_ENDIAN 2 и, собственно, все.

В первом приближении действительно должна - в свое время портировал довольно старую, теперь наблюдаю процесс правок Автором абсолютно совпадающий с моими . И еще не помню точно, но помнится паковки структур там еще нет...
Единственно, что для исключения избыточного кода (в прочем, как и практически любого кода портируемого с восьмибитовиков) надо в нужных местах менять восьмибитовые переменные на естественные 32bit.

Это хорошо что хоть в коде самой FS не надо ничего менять - а что под другие платформы надо и файлы ff.c(tff.c) править? (ужос) Но я имел в виду реализацию diskio.c ? порт всетаки это вещь отдельная - и сама FS в нему не относиться ... нет ли у кого реализации методов из diskio.c для nxp?

Есть. А вы признаетесь, с каким носителем работать собираетесь?

Признаюсь и каюсь что забыл написать
SD карточка(я не знаю - нужно ли еще что-то по этому поводу писать?), плата на 2148.
А вообще в примерах Чана встретил интересную вещь "MMC/SDC (in SPI mode) control module ©ChaN, 2006" - это из заголовка файла mmc.c - типа для mmc и sd карточек драйвер один?

Увы, у меня AT45DB321. Боюсь, они сильно непохожи.Не знаю, не работал с карточками. Но раз файл уже есть, что там остается портировать? запись/чтение SPI и дерганье ногой CS? Это же совсем детская задача.

Если бы все было так просто и писали все портируемый код, а то что и где менять и сам автор редко знает
Да к тому же в новых вариациях уже вроде под MMC/SDSC/SDHC делается, вот думал что поскольку тут на форуме постоянно предлагают эту файловую систему вместо efsl, да и arm7 не мало популярен - уж казалось драйвер для работы в карточками должен у кого-нить иметься - зачем изобретать велосипед! а не взять нормальный отлаженный код. К тому же повторюсь что только начал работу с файловой системой и армами - слишком много всего одновременно

Ну у меня есть и нормальный, и отлаженный, и даже не совсем велосипед и конкретно под LPC-ишные 213x и старше есть. Только вот я его целиком не раздаю именно по причине, что он нормальный и отлаженный .
Ну в какой-то степени рабочих (типа у Автора на его чипе с его карточкой на какой-то скорости работал) в интернете болтается много, если не изменяет память было что-то болгарами (возможно Олимех) писанное и некий телефонный автооветчик на LPC.

Класно, а то я думал их просто нету - а оно все оказалось много проще

и что можно такого придумать в стандартном протоколе и интерфейсе?

В принципе основа есть - сам Чен ее и написал

только не понял почему он так стороной армы обошел - вроде не такая диковинка. Так вот всего-то и надо его avr на arm перевести - не думал что все делают это самостоятельно и не нашелся кто-нибудь с более либерлальными взглядами на opensource
И самое непонятное - ведь есть на svn://mikrocontroller.net в реализации mp3 декодера порт для AT91SAM7S64 (правда непонятно сам Чен его написал или народ переделал). Но только там все в кучу свалено sam+spi protocol. Переделывать плохой код это уж слишком, лучше взять более чистый и с нуля написать под arm.
Ну честное слово - не понимаю где тут не велосипед.

Если кто-то решит проявить жест доброй воли - открыт всем направлениям пока буду сам писать. Но поскольку все это делаю на новом ядре, ide, компиляторе и еще неизвестно каком отладчике и как прикрученому то процесс будет думаю интересный

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

Когда прочитаете про LPC-ишный SSP - подумйте, как его эффективно использовать.
Нет, как попало или скачать из интернету оно тоже можно, но я писал об эффективности.
Ну правильной реализации протокола в интернете я свое время не встетил . Хорошие, которые дали мне пищу для раздумий и идеи для реализации - два встретил. Десятки остальных - совершенно ненормальны, написаны для паркетной работы в лоб и местами покрыты шаманскими знаками.

Да вроде как не обошел.Смотрим известный ресурс http://elm-chan.org/fsw/ff/00index_e.html первый абзац:

FatFs module is an experimental project to implement the FAT file system to small embedded systems. The FatFs module is written in compliance with ANSI C, therefore it is independent of hardware architecture. It can be incorporated into cheap microcontrollers, such as 8051, PIC, AVR, SH, Z80, H8, ARM and etc..., without any change.

Далее еще один ресурс: http://www.siwawi.arubi.uni-kl.de/avr_proj..._arm/index.html
Имеются порты EFSL FatFS как под ЛПЦ так и под САМ

Привет всем!
Не сочтите за оффтоп - просто не хотелась чтобы и эта тема была еще одной из разряда многих незавершенных (или завершеных - так: "хорошо сделаю обязательно отпишусь" ... прошло четыре года ... )
Так вот, процесс получился очень даже замечательный - как мы все и думали
Вот сегодня удалось записать свой первый файл на карточку
Вроде файлик получился что-то типа драйвера SD/MMC под LPC.
Но это все только первое приближение - поскольку не понравилась реализация в примерах задержек на глобальных переменных (хотя пока не думал как сделать - он ведь должен быть на очень короткие интервалы), при том не проверял работу на MMC карточках (нету их), к тому же надо еще и SDHC делать на будущее.
Вот. Но главное что работает - теперь буду смотреть и думать к каком направлении там оптимизировать - интересно! Да протокол надо будет повнимательнее изучить -
.
Ах да, ссылки

очень хорошие! Спасибо! использовал!
А по поводу

Да, в тексте то он есть - а в примерах

нету, я это имел ввиду, то есть портов напрямую Чена нету. (по крайней мере на его сайте)
Ну вроде все! буду двигаться далее! надо еще EFSL поизучать - чтобы выбрать.

Портировал FatFS под LPC21xx.
Создает/читает файл, создает директории. Но как только добавляю функцию f_write в код контроллер куда то улетает . Хотя в симуляторе ничего подобного не наблюдается.
Что за барабашка такая ?
Компилятор RV mdk3.20.

Для Troll.
Выложил спецификацию на SD.
И готовый проект tff + реализация драйвера SD.
Как я уже сказал лично, в драйвере нет защиты от сбоев, ну и может не оптимально все - так как пока переключился на разработку ОС в которой это будет применено. Просто проверил что файлы пишет и сама реализация фат меня устраивает, остальное потом. Можешь дорабатывать - считай что лицензия BSD
Думаю всем будет приятно если что получилось потом сюда тоже выложишь!

Проект был в Eclise. Компилер GCC.