Перейти к содержанию
    

charkin

Участник
  • Постов

    35
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о charkin

  • Звание
    Участник
    Участник

Посетители профиля

1 041 просмотр профиля
  1. Я в другом проекте включал кэши, а область памяти, в которой были размещены буферы для работы с периферией в DMA-режиме настраивал как некэшируемую. Вроде работало. Но это все было в пределах ОЗУ МК, а тут внешняя память. В этом проекте решил попробовать не включать кэши и MPU - прием данных по UART и SPI в DMA-режиме работал нормально..
  2. То есть icf-файл у меня отредактирован верно, а для того, чтобы все работало, необходимо верно настроить регионы памяти в MPU? Кэши можно не включать, правильно понимаю?
  3. Кэш данных и инструкций не включал, MPU не настраивал.
  4. Да, FMC проинициализирован и работает верно - изображение на дисплее есть. Ну и просто скопировать данные из ОЗУ МК в буфер во внешней памяти тоже могу - memcpy() работает.
  5. IAR - ext RAM, FMC, DMA и icf-файл.

    Всем привет. Чип STM32F769, к нему через FMC подключена внешняя ОЗУ (используется для вывода изображения на дисплей). Хочу частично использовать внешнюю ОЗУ для приема данных от UART и SPI. Объявил массив следующим образом : uint8_t rx_buffer[131072] @ ".sram"; В icf-файл вписал данные о новой области памяти: define symbol __ICFEDIT_region_SRAM_start__ = 0xC03B5800; define symbol __ICFEDIT_region_SRAM_end__ = 0xC043CC00; define symbol __ICFEDIT_size_sram__ = 524288; define region SRAM_region = mem:[from __ICFEDIT_region_SRAM_start__ to __ICFEDIT_region_SRAM_end__]; place in SRAM_region { readwrite section .sram }; Проверяю map-файл, вижу что массив размещен во внешней ОЗУ, все хорошо. Но прием данных не работает - в приемном буфере мусор 😞 Пробую читать через SPI, в DMA-режиме. Вопрос : возможно ли в принципе использовать внешнюю память для использования ее периферией, и с DMA? Если да, то что делаю не так?
  6. STM32 USB CDC Host & LTE Модем

    Всем привет. Пробую подключить LTE-модем Telit LE910 к STM32F746 через интерфейс USB (через обычный UART уже обмен есть, но захотелось большего). У этого модема USB-устройство имеет несколько интерфейсов, 2 из них это виртуальные COM-порты, через которые можно отправлять AT-команды. Предварительно подключил модем к компу, поставил с помощью Zadig драйвер CDC и записал обмен с помощью USB Lyzer - обмен с хостом минимален, кроме запроса дескрипторов хост несколько раз отправляет запросы SetLineCoding и GetLineCoding и все. Для ускорения работы взял пример CDC-Standalone для F746-Discovery из CubeMX и переделал его, т.к. только 4-й и 5-й интерфейсы модема являются виртуальными COM-портами (я переделал пример для работы с 4-м интерфейсом). Инициализация и энумерация проходят успешно, но команды SetLineCoding и GetLineCoding работают неправильно : 1)Функция SetLineCoding возвращает статус USBH_BUSY, она вызывается не менее 30 раз, прежде чем вернет статус USBH_OK (ввел специальную переменную-счетчик для этого) 2)Если после того, как функция SetLineCoding вернула статус USBH_OK, еще раз вызвать функиции SetLineCoding или GetLineCoding, то она всегда возвращает статус USBH_BUSY, то есть обмен данными через конечную точку 0 больше не работает. case CDC_SET_LINE_CODING_STATE: set_line_counter++; req_status = SetLineCoding(phost, CDC_Handle->pUserLineCoding); if (req_status == USBH_OK) { CDC_Handle->state = CDC_GET_LAST_LINE_CODING_STATE; } else { if (req_status != USBH_BUSY) { CDC_Handle->state = CDC_ERROR_STATE; } } break; static USBH_StatusTypeDef SetLineCoding(USBH_HandleTypeDef *phost, CDC_LineCodingTypeDef *linecoding) { phost->Control.setup.b.bmRequestType = USB_H2D | USB_REQ_TYPE_CLASS | USB_REQ_RECIPIENT_INTERFACE; phost->Control.setup.b.bRequest = CDC_SET_LINE_CODING; phost->Control.setup.b.wValue.w = 0U; phost->Control.setup.b.wIndex.w = 4; phost->Control.setup.b.wLength.w = LINE_CODING_STRUCTURE_SIZE; return USBH_CtlReq(phost, linecoding->Array, LINE_CODING_STRUCTURE_SIZE); } Буду благодарен за любые идеи, почему не работает обмен с помощью функции USBH_CtlReq.. P.S. На АТ-команды модем тоже отвечает (пробовал функции USBH_CDC_Transmit/USBH_CDC_Receive). telit.pdf
  7. Вот тут - memcpy((uint8_t*)&exch_main_receive_pack+DATA_P_HEAD_SIZE,(uint32_t*)(SRAM_BANK_ADDR + DATA_P_HEAD_SIZE),size-DATA_P_HEAD_SIZE); - копируется 512 байт, SRAM_BANK_ADDR - адрес на шине FMC (#define SRAM_BANK_ADDR ((uint32_t)0x64000000)). DATA_P_HEAD_SIZE - 24 байта : #pragma pack(push,1) typedef struct { uint8_t p_type; uint8_t cmd; uint16_t len; uint32_t addr; //N_sector uint32_t req_cntr; uint32_t len_req; uint32_t len_ans; uint32_t offset; // uint16_t len_part; uint8_t data[BLOCK_SIZE]; }data_packet_t; #pragma pack (pop) #define DATA_P_SIZE sizeof(data_packet_t) #define DATA_P_HEAD_SIZE (DATA_P_SIZE-BLOCK_SIZE)
  8. Выключается - #pragma pack (pop). Ворнингов нет. За идею с указателями и отладчиком спасибо - попробую.
  9. Ну это вроде как последняя выполнявшаяся команда? В окне Call Stack после нее стоит Exception..
  10. Вы про адрес вы окне Fault exception (0x80033ca) и адрес, на котором стоит желтая стрелка? Они разные, но что это значит? Если не сложно, объясните, пожалуйста, поподробнее.
  11. Unaligned access error has occurred, IAR

    Всем привет. Проц STM32H743, периодически происходит падение в HardFault, сообщение в окне Fault exception viewer - An unaligned access error has occurred. Строка, на которой происходит ошибка - memcpy((uint8_t*)&exch_main_receive_pack+DATA_P_HEAD_SIZE,(void*)(SRAM_BANK_ADDR + DATA_P_HEAD_SIZE),size-DATA_P_HEAD_SIZE); Тип exch_main_receive_pack - структура, объявлена с директивой #pragma pack(push,1). Подскажите пожалуйста, как решить проблему (или где почитать на эту тему). Заранее спасибо.
  12. За идеи спасибо! Отвечу по пунктам : 1) Да, должен быть. 2) ПДФ есть, 172 страницы, но описание регистров по моему мнению далеко от подробного, примеров нет. Удалось найти пример использования в сети, но и там не все понятно, впрочем и это уже что-то. Специальной ножки для HS нет. 3-5) С аппаратной частью сложнее - я сам в этом слабо разбираюсь, а коллега, который может помочь, сейчас отсутствует. Почитал еще раз апноут 4860, там при переводе в HS режим сначала останавливают DSI - этого нет в примерах CubeMX. Попробовал так - похоже, что-то зашевелилось, буду рыть дальше.
  13. Написано на HAL. Переключаюсь также, как в примерах, которые идут с CubeMX для платы STM32F469-Discovery. Про это ничего сказать не могу, работаем с тем, что дали.
×
×
  • Создать...