Lyrri

alexp74, спасибо. Помогло.

Здравствуйте. Столкнулся со следующей проблемой. Необходимо максимально быстро читать область памяти с процессора (STM32F212, память RAM) с помощью OpenOCD. Сейчас циклически читаю с помощью команды dump_image. Столкнулся с тем, что вне зависимости от того, какую скорость я устанавливаю через adapter_khz, фактически она остается одной и той же. Проверил с отладчиками J-Link v.8 и ST-Link v.2 На скриншотах приведены параметры запуска OpenOCD и фактическая скорость, снятая логическим анализатором с пина TCK (SWCLK). ST-Link v.2 950 kHz ST-Link v.2 1800 kHz ST-Link v.2 4000 kHz J-Link v.8 8000 kHz Что я пропустил/делаю не так? Кто-то озадачивался скоростью загрузки/выгрузки данных через OpenOCD? Заранее спасибо.

Действительно ))) Спасибо. Я чего-то решил, что компилятор будет ругаться на то, что функция не была объявлена заранее.

Здравствуйте. Для логгирования событий FreeRTOS попробовал подключить Trace Hook Macros (Чип STM32F2xx, компилятор IAR, FreeRTOS v8.2.2) Возникла проблема с местом определения этих макросов. Наткнулся на рекомендацию от Ричарда, где он пишет: "The best place to define hook macros, such as traceTASK_SWITCHED_OUT(), is in FreeRTOSConfig.h. That way the order in which macros are defined is guaranteed to be correct. If you are going to write complex macros then you can put them in their own header file, and include that header file from FreeRTOSConfig.h" Попробовал подключить свой хедер в FreeRTOSConfig.h. Хедер выглядит следующим образом #ifndef LOGGER_H_ #define LOGGER_H_ #include <stdint.h> void logger_init(); void logger_createtask(uint32_t addrname, uint32_t prio, uint32_t stacksize); #define traceSTART logger_init(); #define traceTASK_CREATE(xTask) \ logger_createtask((uint32_t)&xTask->pcTaskName, xTask->uxPriority, \ (xTask->pxTopOfStack-xTask->pxStack)); #endif /* LOGGER_H_ */ Но возникла проблема. FreeRTOSConfig.h также включается в portasm.s и компилятор выдает ошибку при попытке скомпилировать проект. Кто нибудь использовал эти макросы? Где их лучше/правильнее всего разместить?

Ответ от CEO Percepio AB. Недельный лог пока что не доступен

Наткнулся на логгер FreeRTOS от Percepio link. Инструмент показался интересным, но возник вопрос - насколько он необходим? Кто-то пользуется подобными инструментами, или это всего лишь красивая "игрушка"? Хотя, просмотреть недельный лог работы системы было бы наверное интересно.

Использую FreeRTOS, но что это поменяет? Эти обработчики уже задействованы в работе RTOS и лезть в них руками не хотелось бы. Спасибо. Это я видел. Но хотел сделать инициализацию в виде функции dbg_init(); внутри которой инициализируются регистры ITM.

Здравствуйте. Хочу сделать вывод отладочной информации через SWO используя ITM, поскольку ядро позволяет. Для этого нужно сконфигурировать регистры модуля ITM. В часть регистров запись возможна только в привилегированном режиме: Как "красивее" попасть в привилегированный режим, если в процессе работы уже используются SVC, PendSV, SysTick прерывания (на камне запущена RTOS)? Возможно ли вообще попасть в этот режим при таких начальных условиях?

Это все для того чтобы понять что же произошло у конечного пользователя, если что-то пойдет не так. Ведь обычно feedback приходит в виде "А я включил а оно не работает.... Оно то работает то не работает... итд". Перегрузка происходит во вачдогу. Если программа застряла в исключении, то пишется тип исключения и содержание соотв. регистров. Если какая-то из задач (у меня FreeRtos) не "отчиталась" за определенный период времени о том что она жива, также произойдет перезагрузка системы по вачдогу. В этом случае во флеш будет записано имя повисшей задачи.

Выгод то особых и нету (пока). Для анализа "что же произошло" на этапе тестирования достаточно HardFault.

С HardFault вопросов как раз нету. Как, к примеру, BusFault вызвать (кроме, конечно BusFault() )? В каких книгах и интернетах это посмотреть?

В текущем проекте сделал сохранение последнего исключения во внешнюю flash память для дальнейшего анализа (сохранение последней причины перезагрузки системы). Осталось это все дело протестировать. То есть написать тестовый код так, чтобы гарантированно вызвать исключения: NMI, HardFault, MemManage, BusFault, UsageFault. Нашел как вызвать HardFault на просторах этого форума (попытка чтения по невыровненному адресу). void make_hard_fault() { __asm volatile ( "MOVS r0, #1 \n" "LDM r0,{r1-r2} \n" "BX LR \n" ); } Как лучше/правильнее протестировать все остальные исключения?

А что с WF121 (Bluegiga) не так? Вдоволь наковырялся с TiWi-SL (CC3000) - он пока еще сырой.

Нашел в чем проблема, может для кого-то будет актуально. Как только производится запись в ненулевую IN endpoint (функция DCD_EP_Tx()), вызывается функция USB_OTG_EPStartXfer() и устанавливает DREGS->DIEPEMPMSK в 1 для заданого endpoint. После этого, когда TX FIFO окажется пустым, получим прерывание "empty FIFO", флаг которого нигде в библиотеке не сбрасывается. В итоге получаем прерывание, обработчик которого выполняется постоянно. Как исправить: - в файле usb_dcd_init.c находим функцию DCD_WriteEmptyTxFifo() - в этой функции находим следующие строки ep->xfer_buff += len; ep->xfer_count += len; - и после этих строк добавляем следующий код if( ep->xfer_count >= ep->xfer_len){ uint32_t fifoemptymsk = 1 << ep->num; USB_OTG_MODIFY_REG32(&pdev->regs.DREGS->DIEPEMPMSK, fifoemptymsk, 0); break; }

В функциях EPx_Callback вызовы rtos не используются. Данные принятые от ПК отправляются обратно. При инициализации USB использую следующий код: NVIC_PriorityGroupConfig(NVIC_PriorityGroup_4); NVIC_InitStructure.NVIC_IRQChannel = OTG_HS_IRQn; NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 10; NVIC_InitStructure.NVIC_IRQChannelSubPriority = 0; NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE; NVIC_Init(&NVIC_InitStructure); Поскольку вызовы rtos в прерывании не используются, приоритет прерывания выше чем #define configMAX_SYSCALL_INTERRUPT_PRIORITY 191 /* equivalent to 0xb0, or priority 11. */ Мои рассуждения по поводу прерываний верны? Или я где-то ошибся?

Удалось ли решить проблему? Похоже, у меня те же сиптомы.

Есть плата с STM32F207. USB используется как виртуальный com порт (точнее, эмуляция ft4232). Библиотека USB - стандартная USB-Host-Device_Lib_V2.0.0 от STM. При подключении к ПК устройство видится как 4 com порта, принимает данные и возвращает их в эхо-режиме. Все ок. Запускаю FreeRTOS без использования USB. Для простоты создал одну задачу, которая каждую секунду сбрасывает в UART тестовую строку. Тоже все работает. Но при попытке обьединить эти два действия возникла проблема: при подключении по USB к ПК, та частьу программы, которая отвечает за обработку USB продолжает работать (поскольку там вся работа проходит в прерывании USB) а rtos падает где-то через 5 секунд после подключения. После падения rtos, перестает сбрасываться тестовая строка в порт. Попытка остановится на брекпоинте в vApplicationIdleHook() тоже ни к чему не привела. vApplicationStackOverflowHook() переполнения не находит. Выделил по максимуму стека для idle и своей задачи - все равно не работает. Нашел описание подобной проблеммы на форуме STM. Там решение свелось к понижению приоритета прерывания USB ниже системного таймера. Попробовал у себя, хотя в прерывании USB не используются api вызовы rtos. Но и это не спасло отца русской демократии (((. И вот теперь назрело несколько вопросов: 1 Кто-нибуть использовал FreeRTOS совместно с usb device на stm32? 2 В какую сторону копать?

При подключении FT4232 к компу, чип определяется как четыре ком потра (видны в "Диспетчер устройств -> Порты COM и LPT") И все они имеют имя "USB Serial Port". Например USB Serial Port (COM4), USB Serial Port (COM5), USB Serial Port (COM6), USB Serial Port (COM7). Каким образом можно их переименовать в следующие ? USB Serial Port 1 (COM4) USB Serial Port 2 (COM5) USB Serial Port 3 (COM6) USB Serial Port 4 (COM7) Ковыряние в *.inf файлах показало следующее: секция [string] файла fdibus.inf содержит описание: USB\VID_0403&PID_6011&MI_00.DeviceDesc="USB Serial Converter A" USB\VID_0403&PID_6011&MI_01.DeviceDesc="USB Serial Converter B" USB\VID_0403&PID_6011&MI_02.DeviceDesc="USB Serial Converter C" USB\VID_0403&PID_6011&MI_03.DeviceDesc="USB Serial Converter D" То есть, по желанию я могу изменить строковые идентификаторы составного USB устройства. Но если посмотреть файл ftdiport.inf, то секция [string] содержит вего лишь один идентификатор: VID_0403&PID_6011.DeviceDesc="USB Serial Port" Как бы поправить эту секцию, чтобы получить результат, описанный выше?

В stm32 с ethernet (в частности stm32f207) есть некий пин ETH_PPS_OUT, функциональное назначение которого я так и не нашел в даташите. В каких случаях и для чего он используется?

Для отладки в конец скрипта линкера добавляются следующие секции: /* Stabs debugging sections. */ .stab 0 : { *(.stab) } .stabstr 0 : { *(.stabstr) } .stab.excl 0 : { *(.stab.excl) } .stab.exclstr 0 : { *(.stab.exclstr) } .stab.index 0 : { *(.stab.index) } .stab.indexstr 0 : { *(.stab.indexstr) } .comment 0 : { *(.comment) } /* DWARF debug sections. Symbols in the DWARF debugging sections are relative to the beginning of the section so we begin them at 0. */ /* DWARF 1 */ .debug 0 : { *(.debug) } .line 0 : { *(.line) } /* GNU DWARF 1 extensions */ .debug_srcinfo 0 : { *(.debug_srcinfo) } .debug_sfnames 0 : { *(.debug_sfnames) } /* DWARF 1.1 and DWARF 2 */ .debug_aranges 0 : { *(.debug_aranges) } .debug_pubnames 0 : { *(.debug_pubnames) } /* DWARF 2 */ .debug_info 0 : { *(.debug_info .gnu.linkonce.wi.*) } .debug_abbrev 0 : { *(.debug_abbrev) } .debug_line 0 : { *(.debug_line) } .debug_frame 0 : { *(.debug_frame) } .debug_str 0 : { *(.debug_str) } .debug_loc 0 : { *(.debug_loc) } .debug_macinfo 0 : { *(.debug_macinfo) } /* SGI/MIPS DWARF 2 extensions */ .debug_weaknames 0 : { *(.debug_weaknames) } .debug_funcnames 0 : { *(.debug_funcnames) } .debug_typenames 0 : { *(.debug_typenames) } .debug_varnames 0 : { *(.debug_varnames) } Данные секции - это стандартная болванка на большинство случаев жизни? Или в каких-то случаях они модифицируются?

У меня возникла следующая проблемма при отладке(eclipse Helios Service Release 2, zylinCDT, sourcery g++ lite, чип lm3s6950). Если при запуске дебага в теле программы отсутствуют breakpoints, то отладка нормально останавливается на main(). При этом gdb выдает следующее: target remote localhost:3333 main () at main.c:27 27 GPIOPinTypeGPIOOutput(GPIO_PORTF_BASE, GPIO_PIN_0); monitor reset halt 500 kHz JTAG tap: lm3s.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) Only resetting the Cortex-M3 core, use a reset-init event handler to reset any peripherals target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x000001a0 msp: 0x2000fffc monitor soft_reset_halt requesting target halt and executing a soft reset target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x000001a0 msp: 0x2000fffc thbreak main Hardware assisted breakpoint 1 at 0xf6: file main.c, line 25. continue Temporary breakpoint 1, main () at main.c:25 25 SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOF); Если же в теле программы (все равно в каком месте) поставить брекпоинты, то программа начнет выполнятся не останавливаясь на main(), до тех пор, пока не дойдет до брекпоинта. При этом лог gdb немного отличается: target remote localhost:3333 main () at main.c:27 27 GPIOPinTypeGPIOOutput(GPIO_PORTF_BASE, GPIO_PIN_0); monitor reset halt 500 kHz JTAG tap: lm3s.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) Only resetting the Cortex-M3 core, use a reset-init event handler to reset any peripherals target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x000001a0 msp: 0x2000fffc monitor soft_reset_halt requesting target halt and executing a soft reset target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x000001a0 msp: 0x2000fffc thbreak main Hardware assisted breakpoint 1 at 0xf6: file main.c, line 25. continue Program received signal SIGINT, Interrupt. main () at main.c:25 25 SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOF); Note: automatically using hardware breakpoints for read-only addresses. Собственно само отличие в следующих двух строках: Program received signal SIGINT, Interrupt. Note: automatically using hardware breakpoints for read-only addresses. Скрипт инициализации следующий: target remote localhost:3333 monitor reset halt monitor soft_reset_halt thbreak main continue Хотелось бы разобраться, это мой косяк где-то присутствует или такое поведение имеет место быть при отладке

Спасибо. Теперь все встало на свои места.

То есть запись размещает секцию .data в ROM (для хранения) исходя из значения счетчика позиций. А счетчик позиций перед размещением (в данном примере) содержит значение, которое также хранится в Я правильно понял?

В процессе изучения документации линкера для CodeSourcery G++ Lite и примеров скриптов возникли следующие вопросы: 1 Что означает запись *(.text*)? Точнее, почему после .text стоит '*'. Вот пример записи входной секции из документации: 2 Что означает *(vtable)? Я конечно подозреваю, что это как-то связано с таблицей виртуальных функций, но хотелось бы уточнить. Скрипт линкера взят из примеров для LM3S6965 Evaluation Board. Собственно, сам скрипт линкера: MEMORY { FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 0x00040000 SRAM (rwx) : ORIGIN = 0x20000000, LENGTH = 0x00010000 } SECTIONS { .text : { _text = .; KEEP(*(.isr_vector)) *(.text*) /*Почему в конце '*' ?*/ *(.rodata*) _etext = .; } > FLASH .data : AT(ADDR(.text) + SIZEOF(.text)) { _data = .; *(vtable) /*Что и зачем это?*/ *(.data*) _edata = .; } > SRAM .bss : { _bss = .; *(.bss*) *(COMMON) _ebss = .; } > SRAM }

Если Вас не затруднит, опишите пожадуйста пункты со 2 по 11 более подробно. А то меня терзают смутные сомнения, правильно ли я все понял.