Jump to content

    

sergik_vrn

Свой
  • Content Count

    152
  • Joined

  • Last visited

Community Reputation

0 Обычный

About sergik_vrn

  • Rank
    Частый гость
  • Birthday 09/25/1975

Контакты

  • Сайт
    http://
  • ICQ
    0

Информация

  • Город
    Воронеж
  1. JTAG ICE + AT90CAN не пишет flash

    Вынул тут из загашника хз когда купленный имитатор JTAG ICE, на COM-порт. подключили его к AT90CAN, шить пытаюсь с помощью IAR. Версия 3.х и 4.х видеть его отказываются, точнее, говорят, device not supported, а версия 5.11 видит, работает нормально, запускает отладчик, встает на нужный адрес, регистры и порты пишет, но вот содержимое flash не меняет, хотя пишет что downloading, и светодиод желтенький моргает. В какую сторону посоветуете рыть?
  2. Цитата(Aleksey.z @ Aug 17 2009, 15:39) Подскажите каким способом решить данную задачу. Есть последовательная шина I2S (не путать с I2C) нужно организовать буфер чтения с этой шины. Это нужно что бы развязать тактовые сигналы. Приемник и передатчик I2S будут тактироватся от своих кварцев соответственно нужно организовать какой то буфер, вот и думаю на чем это замутить. Есть много способов реализации данной задачи, то ли использовать DataFlash, толи DDR SDRAM в связке с AVR Буфер нужен в принципе не большой, отклонения тактовых частот не больше 400ppm, работать девайс будет не долго. Так же интересует механизм организации работы таким образом: контроллер анализирует оставшуюся свободную емкость памяти и останавливает пополнения буфера, то есть приемник и передатчик работают на разных частотах. Подскажите как подойти к решению данной задачи в общих чертах. если устройство работает недолго, нужен ли ему буфер такого размера? справится ли dataflash по скорости? зачем вообще нужно хранение данных в энергонезависимой памяти, и не будет ли это из пушки по воробьям? или могут возникать сбои питания? если нужен буфер большого размера, почему именно SDRAM, а не SRАM например?
  3. Цитата(piz2383 @ Aug 14 2009, 00:11) Пишу под ARM7. В проекте создается строка static const unsigned char NAME[200]. Которая является идентификатором. Массив храниться во флеши. Со временем мне возможно понадобиться поменять значение этого массива. Для того что бы можно было поменять это значение во флеш нужно что бы адрес начала был выровнен на размер страницы (256). Вопрос: как указать линкеру что данную переменную нужно размещать во флеш по конкретному адресу? если Вам надо поместить массив по конкретному, заранее известному адресу, можно пользоваться директивой @ address, Кодstatic const unsigned char NAME[200] @ 0xFFFFFFF; если же просто надо выровнять границу, то можно положить массив в блок с установленным выравниванием в конфиге линкера, например Код-- .icf --- define block USB_RAM      with alignment = 16 { readwrite section USB_DMA_RAM }; -- .c --- static const unsigned char NAME[200] @ "USB_DMA_RAM";
  4. Ошибки записи FLASH через IAP

    Цитата(GetSmart @ Aug 13 2009, 16:24) В том то и дело, что не про программирование, а про чтение/исполнение кода. Вашу мысль я понял, но кроме упомянутой фразы про исполнение кода о флеше больше ни слова Ладно, посмотрим что покажут испытания, хотя работоспособность/неработоспособность IAP при таких ошибках мне не совсем понятна. Если там тупо от частоты считаются циклы задержки, то ошибка в 1000 раз дала бы соответствующее ухудшение производительности, а если механизм другой, то вообще непонятно, как все это должно работать...
  5. Ошибки записи FLASH через IAP

    Цитата(GetSmart @ Aug 13 2009, 16:15) Ничего полезного здесь не написано. А первичный бутлодер не вызвать из вторичного, кроме как общим сбросом. А вот IAP можно вызывать, у него есть "точка входа". ну я IAP и имел в виду, разумеется. понятно, что ничего полезного, просто про флеш, тем более про его программирование, более нигде ничего вообще не написано
  6. Ошибки записи FLASH через IAP

    Цитата(GetSmart @ Aug 5 2009, 16:41) Если вызывать IAP при включенном PLL, то 72 МГц вполне допустимо. Другое дело, что встроенный bootloader после ресета работает при выключенном PLL и для него допустимо 10..25 МГц. работа идет во вторичном бут-лоадере, перед обращением к функциям первичного устанавливается PLL и включается частота 72MHz. Нигде в документации на 2478 запрета не нашел, а в разделе Introductory написано: ЦитатаThe LPC2400 microcontrollers have 512 kB of on-chip high-speed Flash memory. This Flash memory includes a special 128-bit wide memory interface and accelerator architecture that enables the CPU to execute sequential instructions from Flash memory at the maximum 72 MHz system clock rate. This feature is available only on the LPC2000 ARM Microcontroller family of products. у меня тут другое выяснилось, я обнаружил, что параметр частоты требуется передавать в килогерцах, а не в герцах на это грешу, исправил, теперь пока что идет набор статистики
  7. Ошибки записи FLASH через IAP

    Цитата(Andy Mozzhevilov @ Aug 4 2009, 11:45) По поводу способа заливки софта (JTAG, ISP, IAP). Если я правильно понимаю, то во всех случаях используется встроенный IAP, разница только в способе (и интерфейсе) передачи данных для записи Flash. Тем не менее, если настройки для IAP в собственном загрузчике выполнены корректно, то разница в "качестве записи" между собственным IAP и JTAG мне не понятна. мысли аналогичные. может быть, стоит еще раз сверить настройки... какие они вообще нужны для внутреннего IAP, кроме SYSCLK, конечно?
  8. Ошибки записи FLASH через IAP

    Цитата(shahr @ Aug 3 2009, 17:56) кабель? этот вопрос все равно сводится к достаточности CRC16 для отслеживания возникающих ошибок связи. должен отметить, что подобная же прошивалка используется для записи STR710, там ни разу сбоев не наблюдалось...
  9. Ошибки записи FLASH через IAP

    Цитата(GetSmart @ Aug 3 2009, 17:28) Версия №1 Неправильно указывается частота SYSCLK при вызове IAP. Точнее в IAP передаётся заниженная частота, а на самом деле SYSCLK выше. указываю 72MHz, что в моем понимании и есть SYSCLK. На эту тему были подозрения, но вроде как все правильно. Может, ему на всякий случай чуток завышенную частоту передать, 75МHz скажем? скорость записи не является принципиальным вопросом Цитата(scifi @ Aug 3 2009, 17:33) Я где-то слышал, что в микроконтроллерах LPC для флэш есть ограничение: в каждый 512-байтовый ряд можно дописывать не более 16 раз (пачками, кратными 16 байт). Если число записей больше, то позже могут быть сбои при чтении. У Вас это ограничение не нарушается? перед каждой записью чипа производится его очистка через SBI Кодvoid erase_user_flash() {     prepare_sector(USER_START_SECTOR, MAX_USER_SECTOR);     erase_sector(USER_START_SECTOR, MAX_USER_SECTOR);     check_result(); }
  10. Процессор LPC2478, загрузчик по ком-порту, все замечательно работает за исключением того, что иногда при верификации записанных данных появляются ошибки. Скажем, на 20 записей прошивки размером ~400k один раз возникает ошибка в одном бите (условно говоря, 0x49 вместо 0x4B) в произвольном месте памяти. При этом иногда даже верифицированная прошивка иногда подглюкивает. Когда пишу через j-tag, проблем не возникает, и в переписанной прошивке глюки пропадают сами собой. Процедура обмена по ком-порту использует блоки размером 1К, проверка CRC 16 На что грешить не знаю, может ли быть, что CRC-16 не покажет ошибку в подобной ситуации? Или может кто-то сталкивался с подобными проблемами в филипсовских процах?
  11. Цитата(west329_ @ May 14 2009, 11:47) КодT_EEPROM_Header       __eeprom *EE_Header; если Вы используете указатель, никакой компилятор за Вас его инициализировать не станет. поэтому либо объявляйте статическую структуру в EEPROM, и работайте с ней, либо инициализируйте указатель сами, но тогда имейте в виду, что компилятор под эту структуру память сам выделять не будет (распределение памяти ложится целиком на Вас)
  12. очередной глюк с data abort в отлаженном коде, при вызове виртуального метода. на этот раз с оптимизацией по скорости. полдня убил, лечится, как обычно, снижением уровня оптимизации в конкретной функции. Чувствую, откачусь я на 4.41, мне такие сюрпризы все нервы съедят
  13. Цитата(sergik_vrn @ Feb 5 2009, 11:02) сами понимаете, просто так "взять следующий камень" не так просто, как хотелось бы, при серийном производстве. впрочем, 2478 тьфу-тьфу пока по этим параметрам не напрягает, речь была про STR710, а он-таки самый жирный в линейке. насчет предложенного способа - спасибо, попробую, как только образуется дыра в расписании. щас вот бьюсь, в другом месте вылезли глюки в многократно отлаженном на разных процессорах коде уже подумываю откатиться на 4.41 попробовал собрать проект с оптимизацией по скорости. размер вырос со 130К до 170К, глюки с data_abort в отлаженном коде пропали. Пока работаю так, дальше посмотрим
  14. Цитата(Rst7 @ Feb 4 2009, 18:58) Возьмите следующий камень в линейке. Тем более, что цены на LPC более чем демократичны. Или 2478 - самый здоровый по Flash? Если да, то предлагаю такой способ. Указываете High Speed и руками для каждого файла выбираете ARM или Thumb. Причем, операционку очень желательно в ARM-режиме собирать, веселее будет. А дальше смотреть по месту. сами понимаете, просто так "взять следующий камень" не так просто, как хотелось бы, при серийном производстве. впрочем, 2478 тьфу-тьфу пока по этим параметрам не напрягает, речь была про STR710, а он-таки самый жирный в линейке. насчет предложенного способа - спасибо, попробую, как только образуется дыра в расписании. щас вот бьюсь, в другом месте вылезли глюки в многократно отлаженном на разных процессорах коде уже подумываю откатиться на 4.41
  15. Цитата(Rst7 @ Feb 4 2009, 18:33) Поставили бы Вы оптимизацию High Speed, а не Size. попробую при случае. причина такого выбора метода оптимизации проста, проект здоровый, в самом большом варианте еле-еле помещается в ПЗУ контроллера. А разная компиляция - разные глюки Впрочем, надо будет попробовать все равно