В новых изделиях нужно добавить can и ethernet. Так как старые наработки исполнены на SAM7S для пеtремственности можно было бы использовать SAM7X512, но хотелось бы заложится на более преспективный камушек, тем более в SAM7 нет ни нормальных часов, ни достаточного количества уартов, ни полноценного интерфейса к sd-карте, ни, возможно, достаточного быстродействия из флэш.

К тому же в процессе эксплуатации изделий на sam7s выяснилась неприятная особенность - watchdog при какой-либо перезагрузке ресетит только cpu, вся остальная периферия, включая aic, остается нетронутой. В результате есть шанс что полноценной перезагрузки не произойдет и половина периферии подвисает. У меня вис АЦП(подвисали именно измерения- выдавал нулевые семплы), таймеры счетчики, PIT, вход ресет контроллера тоже, как правило, отваливается при первом удобном случае. И ведь watchdog не поставишь внешний в такой ситуации, так как непонятно какая часть кода в данный момент отвалится. Отловить момент и причину зависания так и не смог, оставлял презагружатся по собаке каждые сутки - нулевой эффект все работает. Что я только не делал чтоб от этой фичи избавится - выключал периферию прежде чем включить, сбрасывал сначала все флажки прерываний в AIC, переключаясь в edge-triggered - все равно не уверен что победил. Watchdog использовали для команд перезагрузки при смене настроек и прошивки - пришлось отказаться и ресетить программно с помощью ресет-контроллера, однако на случай сильных ЭМП и прочего душа остается неспокойной.

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

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

Кстати с еще большими надеждами расстривается 2388.

Ай-яй-яй, а как же мануал почитать? Чтобы сбрасывалось все, нужно не ставить бит WDRPROC в WDT_MR.


А это похоже на недостаточную скорость нарастания VCORE, должно быть больше 6В/мкс.

Так я и не ставлю. Собственно говоря я этот бит даже и не рассматриваю при конфигурировании watchdog. нужное слово собираю без него. А мануал читал уже очень давно, когда делал стартап. Даже забыл что там такой идиотский флаг есть. Спасибо что напугали, лишний раз проверил.



Похоже. Только питается все от линейника lm1117, для питания ядра используется внутренний стабилизатор. На входе у линейника импульсник, соттветсвенно напряжение либо есть - либо нет, не считая конечно емкости на выходе импульсника, может дело в ней. Но без неё, извините, никуда. Проблема в том что я понятия не имею что в этой схеме такого особенного.

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


Ничего в ней нет особенного. Но если требования к скорости нарастания питания не удовлетворяются,
то процессор имеет полное право не работать.

В этой кассе используется LPC2387.

А в этих весах LPC2368.

И это лишь малая часть всех выпускаемых устройств на LPC23xx семействе.

К сожалению это не вопрос веры. Перезагрузку процессор иногда выполняет некорректно. При каких условиях и что именно происходит так и не удалось выяснить. Просто плюнул потому что бился 2 недели башкой об стенку. Искусственно я вызвать стабильный эффект так и не смог. Собственно я никого и не убеждаю, так как не обладаю полными данными. Видимо накладывались какие-то времянки, глюки моего кода. Надеюсь что я от этого избавился.



BOD ему на что, чтобы ресет держать или х..? Или чтобы потом тыкаться в даташит на предмет, а нарастет ли за 1/3 микросекунды питание ядра, которое берется от его собственного стабилизатора? Я понимаю когда питание ядра берется извне. К сожалению схему делал изначально не я, поэтому супервизор туда никто влепить не догадался. Привыкли к тому что все и так работает, без парниковых условий.




И это малая часть, в свою очередь всего лишь малая часть поделок на семах 7 серии )

Вопрос не про объем продукции, а про то какой кровью за это платить.

К тому же в кассах и весах безотказность работы не настолько критична.

Похоже на глюк WDT старых серий, он описан в errat'е.


BOD-то тут каким боком оказался? Он должен вырубить процессор, когда питание опустится до опасного предела. И все, больше он ничего не должен.


В даташит нужно тыкаться до того. А внутренний стабилизатор стартует за 150мксек, так что требования по скорости относятся к 3.3В.

Вся кровь, пот и слёзы уже пролились в ревизиях "-" и "А". Ревизия "В" вылизана. Есть глюк с CAN, но он описан в еррате. C сентября пойдёт ревизия "D", там вообще все глюки исправили. А безотказность в работе критична в любом встраиваемом приложении

Я про него знаю и обхожу как указано. К тому же глюк как раз заключается в том что процессор не запускается, а у меня запускается но начинает глючить. А вот на второй глюк как раз похоже, только условие другое - нестабильное внешнее питание. ревизия кристаллов - В, не помню поправили его в ней или нет.

Если честно ума не приложу как к этому подступиться чтоб выяснить все окончательно.



Я может что-то не понимаю? Я снижаю питание, соответсвенно 3.3 В опускаются ниже плинтуса, а так как я использую АЦП и внутренний стабилизатор, то это очень плохо - BOD должен сработать и остановить cpu чтобы он не натворил дел. Кстати порог его, я так понял изменять нельзя. Далее напряжение снова повышаю, причем повышение могу делать относительно резко - старт должен быть нормальным, но его нет. Чем от такого спасаться?



Такого не бывает!!!


Я имел ввиду что кассу то можно "дернуть". А если устройство где-то внутри автомобиля, да еще в паре сотен километров от тебя вот тут уже хуже.

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

Я тоже. Но почти на 100% уверен, что процессор не виноват.


Так можете, или делаете и контролируете? А то "напряжение либо есть - либо нет" не отражает скорость нарастания.

Пару лет применяли в изделиях RM3400, SAM7A3, SAM7S, SAM7X, SAM7SE - проблем с WDT никаких не замечено. Даже баг из errat-ы наблюдали всего один раз на старой ревизии SAM7S. Одно время (пока руки до RSTC не дошли) мои бутлоадеры делали рестрт именно по WDT - и все процессоры стартовали "как часики" - иначе это меня быстро задолбало бы при отладке и пришлось бы найти в чем дело. Тоже склоняюсь к мнению что у Вас где-то в коде ошибки есть.

Мы пару разновидностей контроллеров на LPC2378 выпускаем, но не используем Ethernet и USB (пока). Проблемы находились только в определённых ревизиях с PLL (рекомендации из errata удовлетворили) и с MAM. Со сторожем известен баг от 2138 - нельзя слишком часто его сбрасывать - на 2378 по традиции программную заплатку оставили - в системном Yield() сброс это учитывает - так что не знаю есть он или нет. Ещё помнится было какое-то несоответствие значений делителей PCLK указанным в DS/UM - не помню уж которых, но кажется это было для UART-ов.
Ну и нужно не забывать об неотлечиваемом баге с инициализацией RTC и потреблением (см. Errata)

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

Я для обработки прерываний использовал callback функции и общий обработчик (по историческим причинам), сейчас переделал на обработчики прерываний и увеличил стек. скорее всего да проблема былав стеках, так как такой эффект происходил чаще после вылета в dataabort из прерываний и соответсвенно перезагрузки. Databort я победил, соответсвенно надеюсь что и презагрузка будет корректной. Очень надеюсь что проблема была исключительно в коде.

lpc2378 тоже не особо перспективный т.к. у NXP на подходе почти аналогичные камни на кортексах.
Из минусов по отношению к SAM7X серии:
Чуть меньше суммарная ОЗУ
ОЗУ фрагментирована на сегменты 32кб, Ethernet, USB, 2кб RTC - ну может это кому то покажется плюсом
Нельзя записывать по встроенную Flash память побитно (как на sam7), только по 16 байт вроде
Ethernet только RMII, т.е. нельзя использовать дешевый камень типа Realtek, придется использовать (в большинстве случаев) кварцовый генератор
Интерфейс к SD карте может работать с DMA только из памяти USB (мне лично также реализация FIFO не понравилась)
Нет красивых библиотечек как у Atmel с inline процедурами для инициализации (ну это только для тех кому нравится с ними работать)
IAP функции ИМХО - как бы скрывают от пользователя то что в SAM7 можно написать в RAM функции так как тебе это нужно
Больше пока не припомню
а в остальном одни плюсы:
Дешевле (1-2$), Быстрее, RTC, 2КБ ОЗУ на батарейке, SD интерфейс (хотя для таких процов преимущества в скорости перед SPI нет никакого), RMII - меньше ног

Правда? И с контроллером TFT LCD на кортексе тоже планируют (типа 2478)? И когда обещают их сделать доступными в продаже?

- Аналогичные камни на M3 появятся не раньше, чем через год.
- Если нужен MII - пожалуйста LPC24xx.
- IAP функции не "как бы" скрывают, а просто не распространяют. Для увеличения производительности встроенного flash используется патентованный модуль, особенности работы которого компании раскрывать особо нет нужды. Плюс для совместимости кода при изменениях в контроллере flash код программы не изменяется.

Честно говоря более преспективными видятся кристаллы 2387 2388. Скорее всего прям с них и начнем.

Вопрос к shashr
Будут ли такие же только на кортексе?



А в чем, собственно, минус? Нельзя выделить массив больше чем 32К?



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

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


Для меня это плюс - не надо тратить кучу драгоценных лап. А вот у X он не работает по еррате

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

Какой PHY посоветуют использующие??



Интересная подробность. Правда сравнить с X не получится.


долбанные индусы [censored]

Будут. LPC1770 уже заявлены в roadmap.
http://www.standardics.nxp.com/products/lpc2000/lpc23xx/ На этой страничке чуть ниже указаны мкросхемы PHY, с которыми гарантированно работает LPC23xx/24xx/17xx

Никакой сложности, фактически встроенный IAP имеет фиксированную точку входа для обращения. Не нее мапится функция, и все делается на С

В остальном читайте документацию на IAP.

Простите меня Александр!!

И спасибо за ответы.



Дык я имел ввиду, что это сложнее чем просто написать свой код.

Это проще - низкоуровневые процедуры работы с Flash уже за вас написали, вам осталось только правильно их вызвать.

Собственно да, почему бы и нет, смотря какой стиль программирования используешь, например обьявить массив для расперделения памяти между пользовательскими процессами в операционках и псевдооперационках
Есть и другой минус - у тебя только одна область (сегмент - сектор, смотря кто какую IDE использует ) DATA, в которую по умолчанию кидаются все глобальные переменные.
Остальные которые не влезли придется распределять средствами компилятора. Что снижает читабельность, портируемость проекта, и возможно источником ошибок.



Нет именно побитно, на Sam7 есть возможность например сбросить какой нибудь Флаг на константно залитой структуре на флэшке. В Lpc для такого флага надо выделить соответственно регион в 16 байт 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF.
Т.е в Sam7 можно на избранный байт 0x55 записать 0x51 и получить 0x51 (естественно вся остальная часть записываемой странички в 256 байт должна быть идентичной той которой лежит).



Кстати щас юзаю тут sam7x512 никто не знает реанимировали ли у него RMII, в роде как в еррате на него я знаменитого Not Functional не нашел ?
И ещё у него 2 флэш контроллера, можно ли одновременно писать в один контроллер и при этом паралельно исполнялся бы код из другого (прерывания к примеру)???



Стоимость важна? если нет тогда бери те что рекомендует NXP и ставит на свои киты.
А так можешь пошношаться с каким нибудь Lan8700 или более неизвестными китайскими образцами (тут кто то мне кидал ссылку на работающий от резонатора и стоимостью в бакс, но использующих его я ещё не встречал).



Там DMA вообще работает только с USB памятью (из той которая на борту)

Так используйте "нормальный"

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

Не нужно ничего "распределять средствами" - линкер прекрасно все и сам распределит, если ему указать ВСЕ ресурсы RAM имеющиеся в его распоряжении.

Я и использую нормальный.

Ну начались теологические беседы
Далее я бы должен спросить какой линкер вы используете, какую модель распределения кучи и какой планировщик задач и т д и т п
Но мне не интересен флуд, я лишь проинформировал человека о возможных (далеко не всех) use cases.

Судя по поднятым проблемам - не совсем

Отвечаю - любой линкер.

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

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

Увы, это больше похоже на ДЕЗинформацию . По этой причине и не смог пройти мимо.

На самом деле проблемы две - выделене более 32K памяти одним куском и потенциальная возможность потери памяти из-за начально дефрагметированной памяти. Все.

Это и называется распределять средствами. Вы распределяете средствами линкера для чего пишите соответсвующий файл типа xcl, icf, xml, sct и т д и т п. Для этого вы вынуждены изучать документацию на линкер при переходе на другой и тратить на это время.
Стандартные методы это ANSI C/C++.

Я Вам благодарен, но Вы пишите какую-то фигню.) Читать документацию на линкер и писать свои файлы скриптов приходится в любом случае, тем более что нужен собственный загрузчик. Также как изучать возможности тулчейна по написанию обработчиков прерывания, стартапов, использованию стандартных и своих библиотечных функций, премещения кода в RAM и т.д. Стандарт языка здесь не причем.