Нужна помощь по инициализации этого процессора.
Я не очень знаком с архитектурой ARM, но есть задача, в которой к данному процу подключены две флешки (Intel J3), для организации 32 разрядной флеш-памяти.
У меня есть исходники инициализации от платы EDB9315, но там стоит одна 16-рязрядная флешка.
в исходниках есть код для чтения 32 разрядной флешки(это определяется по 7 биту в регистре SysCfg 0x8093009C) куда бит ставится кодом начального загрузчика(он там проверяет куда память подключена, и обнаружив ее, в 32 режиме, ставит этот бит).
функция чтения флешки(ее кода производителя и типа девайса), проверяет этот бит и работает с флешкой либо 32 рязрядныи способом, либо 16-ти.
Читаю при это я довольно странные данные. Тип девайса вроде верный - 18H, но тип флешки - 89H(Intel), тогда как производитель - Micron(должно быть вроде 2сH).
Также похоже есть проблема с реальной шириной шины для этой пары флешек. Она похоже 16 разрядная(есть предположение).
Вопрос тут такой.
Нужно ли каким-то образом задавать при инициализации проца ширину шины для флешки(она сидит на CS6), или она (как видно по коду, что я имею) просто определяется по, фактически, ширине шины SDRAM???(чип селект 0).
Сразу предупреждаю, что схему разрабатывал не я, я не электронщик, а скорее программист.
и память и флешка по базовому адресу 0x60000000 отмаплены на их-же физ адреса, насколько я понимаю этот арм.

Короче - кто знает как правильно к EP9307 прикрутить 2 флешки, получить 32 битную флешку таким образом и что нужно делать при инициализации если такай 32 разрядная "флеша" стоит?

Для нормальной работы 32-бит шины нужно соответствующим образом проинициализировать SMCBCR6.

гм...как это я пропустил этот пункт в гайде...StaticMemory Controller.
а я все читал следующий в гайде контроллер - SDRAM, SyncROM, SyncFLASH controller.

вопрос чайника - на схеме устройства две флешки MT28F128J3 просто прилеплены адресами на адресную шину проца, а данные с них идут на шину данных проца: одна флешка - первая половина 32-рязр слова, другая - вторая половина 32-разр слова... и заведен на них чипселект 6.
какой вообще контроллер в этом проце отвечает за такую схематику? почему это static memory?
поскольку я чайник, я думал что это типа SyncFlash.
спасибо за инфу!

MT28F128J3 - это обычная асинхронная флеш. И подключена она к SMC.

Насколько я помню, J3 флешь от микрона по идентам откликается (представляется) интелом. Короче, полный абсолютный аналог.

У них есть оба варианта. У микросхем с микроновским ID есть буква M в названии.

Огромное спасибо. Буду еще вопросы задавать.

если не секрет, на фига Вам 32бит шина на флешь? Это экзотический вариант. Стандартноо все делают 16бит. На ОЗУ - без вопросов. А вот флешь - не понятно.

Объем в два раза больше

скорее всего они поставили и впрямь для увеличения размера флешки.

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

*lp32 = (CMD_READ_ID_CODES<<16) | CMD_READ_ID_CODES; // на обе половины 32-шины данных выставляем команду чтения уида, то есть команда идет в оба чипа. lp32 - указатель на базовый адрес флешки на 32битное слово.

finfo->ManufactureId = (uint16)(((*lp32 >> 16) & (*lp32)) & 0xFFFF);//читаем уид - то есть просто делаем and от ответов обоих чипов- должен получиться ответ одной флешки если они совпадают конечно , считаем уид 16 битным словом.

finfo->DeviceId[0] = (uint8)(*(lp32+1)); //читаем уид девайса, считаем его байтом.

в результате получаем уид производителя = 189H (!), уид девайса - 18H(это правильно).
пугает уид производителя, там лишня спереди единица(по мануалу д.б. 89H). В принципе если порезать его до байта - будет как нужно...
никто с таким эффектом не сталкивался?

Не самый надежный вариант. А если один из ответов будет 0xFFFF?


Где-то сталкивался, кажется. Не обращайте внимание пока.

имеете ввиду - правильный замаскирует неверный FFFF? Угу, согласен. Для корректности надо бы делать OR и проверять. Не обратил внимания.

ок. спасибо. совершенно нет опыта в это деле, вопросы буквально на каждом шагу.
железка кстати тоже только запускается, не тестировалась, потому возможны любые варианты поведения.

Для корректности надо каждый отдельно сравнивать.

еще тупой вопросик.
читаю вот rtc, нужно ли запрещать прерывания при чтении или установке регистров rtc?
по описанию, вроде, инкремент регистра данных делается железом и похоже не подчиняется прерываниям никак. то есть запрещай - не запрещай, в момент чтения может произойти инкремент, если конечно чтение-запись этих регистров не делается самим ARMом как атомарная операция.

А смысл запрещать? Регистр-то один.

ну например если в RTCLoad регистр записать нечто(оно установится в data регистр на следующем секундном тике), и читать data регистр в момент этого установления, то если операция чтения неатомарна, можно получить при чтении какую-нить ерунду. на которую надо как-то реагировать.
или не так?

Неатомарной ее придется специально делать.

Да, а смысл вообще использовать RTC? У цирруса от часов одно название, на самом деле.

а в данном устройстве навороты не нужны. нужно примитивное время, с прерыванием по каждой секунде и с сохранением между сеансами. скорее всего не нужен и аларм.

Ну, воля Ваша. Я бы скорее организовал программное время.

вы лучше скажите, ...вот я слышал что в некоторых SOC можно отключать неиспользуемые блоки(или я это слышал не о том)... а нам не нужны например тачскрин, ac'97, ethernet. Их можно как-то отключить вообще?

Лишнее можно отключить в регистрах PwrCnt и DeviceCfg.

отлично!
еще вопрос в догонку...
позвонил разработчику девайса, он сказал, что ему мол кажется, что можно код пускать прям из пресловутой флешной пары, что мы обсуждали выше. то есть без копирования в озу(видимо потому они там 32-шину и сделали). Рассчитывают туда положить весь исполняемый код и пускать оттуда...
Мануал к флешке имеет какие-то загадочные тексты вроде -
Similarly, program suspend mode enables the user to suspend programming to read data
or execute code from any unsuspended blocks.

Флешка имеет команду -



я правильно понимаю, что прицепив флешку с статическому контроллеру, запрограммировав ее всякими там командами записи, а потом переведя в режим - read arraу, она прикинется простой такой ромкой, и оттуда можно исполнить код непосредственно?

Правильно понимаете.

У цирруса есть родная утилита для загрузки флеш, в том числе Micron/Intel. Не очень удобная, прямо скажем, но должна работать.

если вы имеете ввиду download.exe c нулевым и первым загрузчиком(что потом грузнут редбут во флеш), то они у меня есть, я их и использовал как "заимствованный код". там пришлось некие вещи переписать. А консольную прогу(вместо download.exe) я написал свою. протокол полностью поменял. это позволило совбодно работать через компорт на 115200(раньше вроде не тянуло в силу плохого исходного протокола, и переполнения фифо у порта проца(скорее всего)) теперь бывший первый загрузчик, у меня сильно помощнел, превращаясь в прикладную и тестовую программу. В него я теперь и добавляю всякие инициализации и прочий HAL(потому и задаю вопросы).
Дело в том что плат несколько и нужна как тестовая прога(чтобы проверять их работоспособность), так и собснно прикладная прога.
Работаю над этим делом я один, задача очень раскиданная по "предметныи областям", а денег почти не платят. Если б знал - не стал и браться бы

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

Да, код у них - говно редкостное.

Для себя написал загрузчик, живущий в FIFO EMAC'а - хотя бы стартует быстро.

я хотел загручик записать в eeprom флешку. пока правда не сделал этого.

вопрос - у меня какие-то баги...есть подозрение, что это в силу возможности переупорядочивания команд arm-gcc при оптимизации.
как мастера пишут в softlock регистры этого проца?
можно это делать на си безопасно(то есть сделав и разлок регистра, и запись значения на си), или стоит это делать асмовой вставкой.
вот не могу вспомнить(если это вообще есть), как заставить gcc локально не переупорядочивать команды.

вопрос с порядком команд снимается.
это я пускал uart3 глядя в куд что лежит в этом download у цирруса на сайте.
в инициализации уарта1 у них ошибка.

должно бьть так. с комментом(тут те же самые команды, но для уарта3)



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

такое вот очередное наблюдение за качеством кода от цирруса

SoftLock можно безопасно писать на C - порядок volatile-обращений компилятор менять не имеет права.

Порядок записи регистров UART'а описан в даташите. Это явно лучший источник информации, хотя и в нем есть косяки

aaarrr,
- а вы какую ос ставили на этот проц?
- есть ли либа типа хала для этого проца, чтобы какие-то стандартные вещи с ним делать более абстрактно?
- какие тулчейны вы с ним использовали(используете)? Я пока все далаю все под winarm.

Пробовал Линукс, сейчас использую FreeRTOS со своим набором библиотек периферии. Работаю исключительно под RVDS.

вопрос. а есть какие-то особенности работы с портом HGPIO, конкретно - пятый бит. У нас на железке это сигнал разрашения некоего напаянного устройства, что должно зажигать на себе светодиодики.пишу в HGPIO[5](сконфигурировав как выход) единицу-ничего не происходит(разрешение устройства по единице). Читаю бит порта обратно - единица стоит.
или с железкой проблема...или я что-то с этим портом неверно сконфигурировал.
я просто конфигурировал его как пин-выход, и прописал туда 1.

У порта H каких-то особенностей нет. Ставите HonIDE в DeviceCfg, и спокойно работаете.

а у ep9307 такого бита нет - HonIDE.
у него нет IDE интерфейса.

У него есть такой бит
Т.е. интерфейса нет, а бит (11 бит DeviceCfg) есть, и он работает.

поиск HonIDE по доке - ep9307 user guide ничего не дает.
визуальный осмотр битов регистра DeviceCfg - тоже ничего не дает.
там правда есть три неназванных бита, b11, b10, что должны быть установлены в 1,
и b5 в нуль.
один из них я есть искомый бит?



сильный ход со стороны разработчиков! вот поди пойми, что это связано с H портом.

а чтение пинов сконфигурированных на вывод дает варианты
1.всегда нуль
2.всегда соотвествует записанному в пин
3.соответсвует реальному напряжению на ноге порта.
вот какой?

я взвел эти биты в DeviceCfg
несколько пинов в H сконфигурированы как выход
пишу в H порт 0xFF, читаю обратно - имею нуль.

Третий:

Правда, выходы никогда не читал.

у меня читаются стойкие нули из HDR.
из регистра HDDR(направления) читается верно - те биты что аутпуты - там единицы.
щас буду читать DeviceCfg, что там стоит...

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

вопрос по uart3.
инициализировал я его, запустил. на loopback он работает, то есть читает сам себя- я просто пишу а uart3 символы, потом читаю их, и вывожу через uart1(этот работает правильно) на консольную прогу в писюк.
но читать устройство, по схеме присоединенное к ногам его, он не хочет. это устройство активно, мигает свтодиодиками, по паспорту должно стоять по умолчанию либо в 4800, либо в 9600, 8 бит символ, один стоп-бит, без четности. уарт3 так и выставлен(пробовал обе скорости). не читает.
варианты - проблемы хардверные - с самим устройством(это gps модуль - может в него нужно сначала команды какие-то посылать? но разработчик божится, что оно должно на 9600 сразу стоять, и гнать данные в своем протоколе), с разводкой присоединения его к пинам уарт3...

или что-то софтверное, то есть у меня. могут ли быть какие-то подводные камни в инициализации этого порта, если он таки на loopback себя читает?

А если на UART3 подать сигнал с UART1 или компьютера? Никаких подводных камней при работе с UART3 нет.

ну уарт3 особо ничего не подашь. он наглухо разведен на gps-приемник. если только на ноги самого приемника проводки крутить. но я дома работаю, да и плата мелкая. испорчу.
пока ковыряю протокол приемника, может он просто не хочет отвечать, пока ему что-нить не скажут?

Осциллографом посмотрите тогда. Внутренний loopback практически ничего не покажет в плане ошибок настройки скорости и протокола.
Еще можете поставить заведомо большую скорость (115200, например). Если UART ничего не принимает, то с большой вероятностью на вход ничего не приходит.

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

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

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

все оказалось хуже. на приемнике еще и непропай.
он правильно работает, если его еше и пальцем к плате прижимать
..это столько я бился с этим портом!!!

вопрос.
в железке для общения по i2c используются пины EECLK и EEDAT проца.
эти пины вроде есть пины G[0], G[1].
дабы настроить пины в инициализации i2c драйвера я делаю следующее
PGDDR |=3 //ставим два младших бита в регистре направения G как выходы
EEDRIVE |=3 //ставми эти же биты в регистре драйверов EECLK и EEDAT. они д.б. с открытым стоком.
далее просто пишем и читаем(не переводя G[0]G[1] как входы) биты G[0],G[1] в программной реализации i2c.
не нужны ли еще какие-то танцы с бубнами в данном случае?


кстати правильно ли я понимаю, что в случае если порт стоит как "открытый сток", запись единицы - размыкает выходной ключ, и напряжение тянется вверх резистором. а если записать нуль - ключ замыкается - и напряжение падает в нуль?

Нужны, если используется external boot - тогда на EECLK должен быть pull-down, и открытый сток уже не катит.


По идее, да.

У меня почему-то используется EEDrive = 0. Ну, с SCL все понятно, т.к. external boot, а вот зачем SDA в режиме эмуляции открытого коллектора - не помню, хоть убей

ну там по стандарту i2c обе линии - монтажное И.
sda видимо потому монтажное и, - чтобы читать например акноледж на посланный байт. тогда в 9 такте мастер делает высокий потенциал на SDA(закрывает свой ключ), а приемник открывает ключ и потенциал становится низким. мастер воспринимает это как подтверждение.

а у вас EEпины используются для I2C?
тогда почему EEDrive=0, в доке написано что для открытого коллектора должна быть единица.

Вы меня не поняли. SDA у меня является открытым коллектором, но сделано это не при помощи установки бита в EEDrive, а вручную. SCL вообще тянется пушпулом, но у меня нет периферии, которая умеет затягивать клок.
Почему я сделал так, а не иначе - не помню.

нашел какие-то мутные непонятки с этими пинами в связи с реализацией I2C
1. проц является мастером и потому дает клоки. также его эти две ноги стоят в положении открытый коллектор.
2. попытка изменить пины 0,1 в регистре G приводит к читке регистра, изменению бита и записи обратно в регистр. Но при чтении регистра порта читаются не значения туда прописанные, а значения стоящие на ногах проца(которые могут отличаться от прописанных в порт, в силу монтажного И). таким образом например запись в первый бит(DATA) регистра G, может привести к сбросу в нуль значения записанного в бит 0 (CLOCK)(потому что клок удерживался слейвом в это время на нуле).
то есть нужно иметь локальную переменную(якобы регистр порта), все битовые работы делать с ней, а потом, просто писать в порт эту перемнную(байт), физически не читая его.

А что у Вас на I2C висит? Может, не стоит и напрягаться?