sergik_vrn

Вынул тут из загашника хз когда купленный имитатор JTAG ICE, на COM-порт. подключили его к AT90CAN, шить пытаюсь с помощью IAR. Версия 3.х и 4.х видеть его отказываются, точнее, говорят, device not supported, а версия 5.11 видит, работает нормально, запускает отладчик, встает на нужный адрес, регистры и порты пишет, но вот содержимое flash не меняет, хотя пишет что downloading, и светодиод желтенький моргает. В какую сторону посоветуете рыть?

если устройство работает недолго, нужен ли ему буфер такого размера? справится ли dataflash по скорости? зачем вообще нужно хранение данных в энергонезависимой памяти, и не будет ли это из пушки по воробьям? или могут возникать сбои питания? если нужен буфер большого размера, почему именно SDRAM, а не SRАM например?

если Вам надо поместить массив по конкретному, заранее известному адресу, можно пользоваться директивой @ 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";

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

ну я IAP и имел в виду, разумеется. понятно, что ничего полезного, просто про флеш, тем более про его программирование, более нигде ничего вообще не написано :(

работа идет во вторичном бут-лоадере, перед обращением к функциям первичного устанавливается PLL и включается частота 72MHz. Нигде в документации на 2478 запрета не нашел, а в разделе Introductory написано: у меня тут другое выяснилось, я обнаружил, что параметр частоты требуется передавать в килогерцах, а не в герцах :) на это грешу, исправил, теперь пока что идет набор статистики

мысли аналогичные. может быть, стоит еще раз сверить настройки... какие они вообще нужны для внутреннего IAP, кроме SYSCLK, конечно?

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

указываю 72MHz, что в моем понимании и есть SYSCLK. На эту тему были подозрения, но вроде как все правильно. Может, ему на всякий случай чуток завышенную частоту передать, 75МHz скажем? скорость записи не является принципиальным вопросом перед каждой записью чипа производится его очистка через SBI void erase_user_flash() { prepare_sector(USER_START_SECTOR, MAX_USER_SECTOR); erase_sector(USER_START_SECTOR, MAX_USER_SECTOR); check_result(); }

Процессор LPC2478, загрузчик по ком-порту, все замечательно работает за исключением того, что иногда при верификации записанных данных появляются ошибки. Скажем, на 20 записей прошивки размером ~400k один раз возникает ошибка в одном бите (условно говоря, 0x49 вместо 0x4B) в произвольном месте памяти. При этом иногда даже верифицированная прошивка иногда подглюкивает. Когда пишу через j-tag, проблем не возникает, и в переписанной прошивке глюки пропадают сами собой. Процедура обмена по ком-порту использует блоки размером 1К, проверка CRC 16 На что грешить не знаю, может ли быть, что CRC-16 не покажет ошибку в подобной ситуации? Или может кто-то сталкивался с подобными проблемами в филипсовских процах?

если Вы используете указатель, никакой компилятор за Вас его инициализировать не станет. поэтому либо объявляйте статическую структуру в EEPROM, и работайте с ней, либо инициализируйте указатель сами, но тогда имейте в виду, что компилятор под эту структуру память сам выделять не будет (распределение памяти ложится целиком на Вас)

очередной глюк с data abort в отлаженном коде, при вызове виртуального метода. на этот раз с оптимизацией по скорости. полдня убил, лечится, как обычно, снижением уровня оптимизации в конкретной функции. Чувствую, откачусь я на 4.41, мне такие сюрпризы все нервы съедят :(

попробовал собрать проект с оптимизацией по скорости. размер вырос со 130К до 170К, глюки с data_abort в отлаженном коде пропали. Пока работаю так, дальше посмотрим

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

попробую при случае. причина такого выбора метода оптимизации проста, проект здоровый, в самом большом варианте еле-еле помещается в ПЗУ контроллера. А разная компиляция - разные глюки :( Впрочем, надо будет попробовать все равно

ну, собственно, если IAR сам будет выбирать режим, то вариант 1 будет трудно реализовать на практике... пока что влепил #pragma optimize = medium для этих двух функций, полет нормальный. IAR 5.20, кстати, ведет себя аналогично, а вот в 4.41 подобных глюков не было (правда, там процессор STR710)

прикрепил листинг-файл IAR ARM 5.30.1, LPC 2478, оптимизация максимальная(hz), все параметры вызова компилятора есть в листинге listing.rar

ну я вообще-то задумался, откуда там thumb, но понимания от этого не прибавилось :) кстати, если процедуру сделать __arm (кстати, в порте под STR710 она именно __arm __interwork), результат не меняется, буква в букву однако, это компилятор такой код генеряет. и, судя по всему, мешает thumb c arm в целях оптимизации (во всяком случае, вызов *pxTopOfStack = portNO_CRITICAL_NESTING; явно не отсюда приплетен. ошибка?

во время выполнения FreeRTOS непонятным образом сами собой запрещались прерывания. Путем несложной трассировки выяснил, что происходят они при парном вызове vPortEnterCritical() - vPortExitCritical(), по принципу portTickType xTaskGetTickCount( void ) { portTickType xTicks; /* Critical section required if running on a 16 bit processor. */ taskENTER_CRITICAL(); { xTicks = xTickCount; } taskEXIT_CRITICAL(); return xTicks; } сами процедуры с виду простейшие void vPortEnterCritical( void ) { /* Disable interrupts first! */ __disable_interrupt(); /* Now interrupts are disabled ulCriticalNesting can be accessed directly. Increment ulCriticalNesting to keep a count of how many times portENTER_CRITICAL() has been called. */ ulCriticalNesting++; } /*-----------------------------------------------------------*/ void vPortExitCritical( void ) { if( ulCriticalNesting > portNO_CRITICAL_NESTING ) { /* Decrement the nesting count as we are leaving a critical section. */ ulCriticalNesting--; /* If the nesting level has reached zero then interrupts should be re-enabled. */ if( ulCriticalNesting == portNO_CRITICAL_NESTING ) { __enable_interrupt(); } } } portNO_CRITICAL_NESTING разумеется = 0 однако, что я получаю при трасировке: ??vPortPreemptiveTick_0: 00017E5C 004000E0 DC32 0xE0004000 __disable_interrupt(); vPortEnterCritical: vPortEnterCritical: 00017E60 E10F0000 MRS R0, CPSR 00017E64 E38000C0 ORR R0, R0, #0xC0 00017E68 E121F000 MSR CPSR_c, R0 ulCriticalNesting++; 00017E6C E59F003C LDR R0, [PC, #+60] ; [??DataTable1 (0x17EB0)] =ulCriticalNesting (0x4000F3B8) 00017E70 E5901000 LDR R1, [R0, #+0] 00017E74 E2811001 ADD R1, R1, #0x1 до этого момента все выполняется как надо, адрес в R0, правильное значение в R1 *pxTopOfStack = portNO_CRITICAL_NESTING; Next label is a Thumb label ?Subroutine0: .text_19: 00017E78 6001 STR R1, [R0, #0] не имеет никакого эффекта, значение не обновляется return pxTopOfStack; 00017E7A 4770 BX LR не выполняется вообще соттветственно, дальше выполняется vPortExitCritical: if( ulCriticalNesting > portNO_CRITICAL_NESTING ) vPortExitCritical: vPortExitCritical: 00017E7C E59F002C LDR R0, [PC, #+44] ; [??DataTable1 (0x17EB0)] =ulCriticalNesting (0x4000F3B8) 00017E80 E5901000 LDR R1, [R0, #+0] 00017E84 E3510000 CMP R1, #0x0 поскольку значение ulCriticalNesting не было инкрементировано, проверка отрицательная, дальше выход 00017E88 0A000007 BEQ ??vPortExitCritical_0 ; 0x17EAC ulCriticalNesting--; 00017E8C E5901000 LDR R1, [R0, #+0] 00017E90 E2411001 SUB R1, R1, #0x1 00017E94 E5801000 STR R1, [R0, #+0] if( ulCriticalNesting == portNO_CRITICAL_NESTING ) 00017E98 E5900000 LDR R0, [R0, #+0] 00017E9C E3500000 CMP R0, #0x0 __enable_interrupt(); 00017EA0 010F0000 MRSEQ R0, CPSR 00017EA4 03C000C0 BICEQ R0, R0, #0xC0 00017EA8 0121F000 MSREQ CPSR_c, R0 } ??vPortExitCritical_0: 00017EAC E12FFF1E BX LR ... итог - после выхода из vPortEnterCritical значение ulCriticalNesting нулевое, прерывания запрещены, вызов vPortExitCritical не имеет значения. При уменьшении уровня оптимизации все нормализуется. volatile не влияет на исполнение. Поскольку я в ассемблере мягко говоря не силен, одолеть эту задачку мне оказалось не по зубам

а зачем Вы вводите новый сегмент? разместите в области загрузчика основные стандартные сегменты программы (CODE, и тд.) например: /* Code memory - this line is generated with preprocessor.xls */ -Z(CODE)INTVEC,FAR_F,SWITCH,INITTAB,CODE,NEAR_F=1E000-1FFFF

большое спасибо за подсказку! нашел, разобрался

Исходные данные: IAR 5.30 + LPC2478, ЖКИ TFT, внешняя SDRAM в качестве буфера индикатора. при работе наблюдаются периодические неприятные помехи на индикаторе. опытным путем было установлено, что помехи вызываются некоторыми операциями чтения/записи SDRAM (в том числе в участки памяти, не находящиеся внутри буфера ОЗУ). Написал тестовый цикл for (;;) { int y1 = 0, y2 = 200; int x1 = 0, x2 = 200; for (; y1 <= y2; ++y1) { volatile u16 *from = screen_shadow + x1 + (y1 * C_GLCD_H_SIZE); volatile u16 *to = screen_buffer + x1 + (y1 * C_GLCD_H_SIZE); for (int i = x1; i < x2; ++i) *to++ = *from++; } } сперва грешил на размерность указателей (8/16/32 бита), потом выяснилось, что дело не в этом, а в уровне оптимизации. при level = medium все стоит как вкопаное, как только ставлю high - помехи. при этом при high level от компилятор от исходного кода ничего не оставляет, все ссылки идут куда-то в недра memcpy, с использованием жутких конструкций типа LDMIA, STMIA, LDMCSIA и проч. Конечно, причина ясна, можно обойти, но собирать весь проект со средним уровнем оптимизации очень не хочется, выискивать по всему коду и обвешивать обращения к SDRAM прагмами тоже нет никакого желания. volatile не помогает ни коим образом. может, что-то еще посоветуете?

если речь про IAR, то вся информация о регистрах для отладчика лежит в файле *.ddf. Убедитесь, что Вы выбрали в настройках отладчика правильный файл, если же сам файл с ошибками и не содержит нужной информации, его можно поправить руками (или найти в сети исправленный)

непохоже, там величины порядка 160 байт (zero-init = 50 байт). в любом случае, насколько я ничего не понимаю, упаковку инициализаторов надо включать принудительно в .icf?

самые первые впечатления проект под LPC2478, макс. оптимизация по размеру IAR 5.20 130 114 bytes of readonly code memory 58 646 bytes of readonly data memory 742 306 bytes of readwrite data memory IAR 5.30.1 133 236 bytes of readonly code memory 58 632 bytes of readonly data memory 742 310 bytes of readwrite data memory еще один проект, под STR710 собираю под 4.41, т.к. под 5.20 при максимальной оптимизации по размеру оверхед кода (RO memory) составляет примерно +0x250 байт, под 4.41 примерно столько же остается свободно. под 5.30.1 оверхед составил 0x557 байт. Судя по всему слова в whatsnew об оптимизации по размеру относятся всетки исключительно к Cortex :(