Jump to content

    

sst78rus

Участник
  • Content Count

    21
  • Joined

  • Last visited

Community Reputation

0 Обычный

About sst78rus

  • Rank
    Участник

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. TouchGFX и 32 битная SDRAM

    Это как одна из версий, если есть проблемы при работе с DMA. При отключенном кэше mpu не нужен, будет и без него работать. Я просто сталкивался с интересными ошибками, когда данные в кэше лежат не сначала 32 битной строки и при сбросе кэша портились "соседние" данные. Хотя если вы hal используете, то там это учтено. Проверить это проще всего, выключив для теста кэш. А с выключенным кешем, вам и mpu не нужно, можно и его выключить на время теста. А без TouchGFX вывод работает? Ну и опять же, в качестве версии для проверки - а на самом деле, в том месте где у вас полосы, какой цвет лежит? Соответствует содержимое видеобуфера изображению?
  2. TouchGFX и 32 битная SDRAM

    Кэш данных включен? Попробуйте выключить кэш и mpu.
  3. А EDU v10 сам обновится до v11, раз уж железо одинаковое, или нужно патчить?
  4. Добрый день. Есть в наличии JLink v9.40 от китайцев. Обновляется (пока :) ) штатным образом, на V6.60 обновился до V9 compiled Dec 13 2019. Есть ли смысл менять его на официальный JLink EDU? Есть ли у V10 (или уже V11?) версии EDU аппаратные преимущества? В терре EDU версия есть в наличии и стоит не великих денег. Поясню суть вопроса: при работе с Segger SystemView иногда не хватает скорости и теряются данные (SystemView пишет, что область overflow). Происходит только когда очень много событий записывается. У меня это в момент работы с USB на Freertos. Решит ли проблему замена китайского V9.40 на официальный JLink EDU v10?
  5. А можно так же сделать средствами GCC? Я имею ввиду, при сборке проекта положить то, что нужно загрузить в МК в один бинарник, а то, что в QSPI в другой? С самой загрузкой вроде бы более менее понятно. Для st-link есть примеры, для j-link вроде бы тоже видел.
  6. STM32H7, SPI, прием с DMA

    Похоже что эта проблема описана в Errata. По описанию я сразу не признал "Spurious DMA Rx transaction after simplex Tx traffic" Решение - сброс SPI перед включением DMA на прием. Сброс через SPE бит не помогает, делаю RCC->APB2RSTR |= RCC_APB2RSTR_SPI1RST; __NOP(); RCC->APB2RSTR &= ~RCC_APB2RSTR_SPI1RST; После этого, естественно, надо снова инициализировать SPI. В новых ревизиях вроде бы поправили.
  7. STM32H7, SPI, прием с DMA

    Это устанавливается при помощи DMAMUX. DMAMUX1_Channel13->CCR = 37; //SPI1_RX Каналы DMAMUX связаны с каналами DMA. Связь там вот такая: DMAMUX1 channels 0 to 7 are connected to DMA1 channels 0 to 7 DMAMUX1 channels 8 to 15 are connected to DMA2 channels 0 to 7 DMAMUX2 channels 0 to 7 are connected to BDMA channels 0 to 7 Или проще говоря: DMA1_Stream_x -> DMAMUX1_Channel_x DMA2_Stream_x -> DMAMUX1_Channel_(x+8) А к чему конкретно из периферии будет подключен канал DMA устанавливается в CCR регистре DMAMUX. Для каждого источника свой номер, они в RM указаны. Для DMAMUX1 в моем случае это: 37 spi1_rx_dma 38 spi1_tx_dma
  8. STM32H7, SPI, прием с DMA

    Добрый день. Осваиваю SPI на МК H743. Без использования DMA отправляю и получаю, все работает. Отправлять с DMA тоже получается, а вот с приемом какая-то странность. Отправляю устройству 7 байт при помощи DMA2_Stream6, получаю при помощи DMA2_Stream5. Инициализация DMA: RCC->AHB1ENR |= RCC_AHB1ENR_DMA2EN; // DMA2 clock enable; // Set the peripheral and memory addresses: DMA2_Stream6->PAR = (uint32_t) &(SPI1->TXDR); DMA2_Stream6->M0AR = (uint32_t )LIS3DH_CMD_LIST; DMA2_Stream6->CR = 0; DMA2_Stream6->CR |= (1u << DMA_SxCR_DIR_Pos)|\ DMA_SxCR_MINC; DMA2_Stream6->NDTR = sizeof(LIS3DH_CMD_LIST); //DMA transfer length DMAMUX1_Channel14->CCR = 38; //SPI1_TX DMA2_Stream5->PAR = (uint32_t) &(SPI1->RXDR); DMA2_Stream5->M0AR = (uint32_t )response; DMA2_Stream5->CR = 0; DMA2_Stream5->CR |= DMA_SxCR_MINC; DMA2_Stream5->NDTR = sizeof(LIS3DH_CMD_LIST); //DMA transfer length DMAMUX1_Channel13->CCR = 37; //SPI1_RX Память с которой работает DMA находится в D2, выравнивание на 4 сделано, тактирование SRAM2 включено. uint8_t RAM_D2 ALGN4 LIS3DH_CMD_LIST[] = {0xE8,0x0,0x0,0x0,0x0,0x0,0x0}; volatile uint8_t RAM_D2 ALGN4 response[sizeof(LIS3DH_CMD_LIST)]; В реф. мане описана процедура запуска передачи при помощи DMA, делаю как описано.: - отключаю SPI для изменения CFG1 - Устанавливаю в CR2 количество байт в пакете, чтобы по окончанию поднялся CS - Включаю RXDMAEN (п.1) - Включаю DMA (п.2) - Включаю TXDMAEN (п.3) - Включаю SPI (п.4) В таком варианте передача не начинается, надо еще CSTART бит выставить. SPI1->CR1 &= ~SPI_CR1_SPE; SPI1->CR2 = 7; SPI1->CFG1 |= SPI_CFG1_RXDMAEN; //RX DMA2_Stream5 -> CR |= DMA_SxCR_EN; //TX DMA2_Stream6 -> CR |= DMA_SxCR_EN; SPI1->CFG1 |= SPI_CFG1_TXDMAEN; SPI1->CR1 |= SPI_CR1_SPE; SPI1->CR1 |= SPI_CR1_CSTART; Результат проверяю по флагам DMA шагая в отладчике и в логическом анализаторе. После включения SPI1->CR1 |= SPI_CR1_SPE устанавливаются флаги: TCIF6, HTIF6 (dma передачи) и это вроде понятно. А так же флаги TCIF5 и HTIF5 (dma приема) и это совсем не понятно. Физической передачи при этом не происходит. С передачей, как я понимаю, DMA отправляет все в FIFO SPI и поэтому выставляет флаги окончания. После выставления флага CSTART происходит реальная передача в шину. Я в лог. анализаторе вижу именно то, что и ожидаю. А вот с флагами DMA на прием я не понимаю, почему после включения SPI_CR1_SPE DMA выставляет флаги окончания, если ничего еще не было передано. И выглядит все так, как-будто передача действительно была, NDTR становится в 0. Но реальной передачи еще не было и флаг RXP в SPI не поднимался. Реальная передача, после выставления CSTART уже естественно ничего не меняет в приемном DMA. А в регистрах SPI я как раз вижу, что после передачи принятые данные остались в FIFO, стоит RXP. Что я делаю не правильно?
  9. STM32H7 SDMMC

    Вот пример работы https://github.com/Sergey1560/h7_sdmmc Это не готовая библиотека, а просто пример, чтобы проверить работает ли вообще :) В данном примере выключен режим работы карты HighSpeed. Код переключения в этот режим скопипастил (источники в sdio.h есть), на F4 работало вроде бы быстрее. Под h7 его надо переписать. В sdio.c объявлен здоровый массив buf_copy. Я код взял из готового проекта и там иногда от FATFs приходил запрос на запись не выровненного буфера, от чего DMA падал в hardfault. Я просто копировал в выровненный буфер и уже его читал/писал в карту. Сейчас правда у меня есть подозрения, что FATFs передавал не выровненный блок потому, что я его не выровненным передавал FATFs :) Вообщем обратите на это внимание. Я добавил вывод сообщений, если в функцию чтения/записи на SD передается не выровненный блок, в тестовой записи-чтении срабатываний не было. Тот пример, что в коде, пишется со скоростью около 1.2Мб/с, читается около 8.
  10. STM32H7, LTDC, FIFO underrun

    Да, сделал выравнивание на 8 и заработало. Наличие в этом регионе памяти других переменных не мешает, никаких ограничений на доступ к памяти от CPU я не заметил. Однако оказалось, что такая же ошибка возникает и при установке "окна" слоя определенной ширины. Я не успел сегодня сильно потестировать, но столкнулся со следующим: У меня шрифт размером 33*47. Рисую 1 символ. Если делаю окно слоя 33*47, сыпятся ошибки FIFO underrun. Отрисовывает прямоугольник правильного размера, но внутри мусор. Если сделать 32*47, то ошибок нет, внутри видно символ, но естественно "перекошенный". Если сделать 40*47 и лишнее в каждой строке добить цветом фона - выводит без ошибок и то, что и ожидалось. Т.е. тоже работает на ширине кратной 8 и сбоит на не кратной. Я пока немного отложил этот вопрос. Мне не сильно надо делать весь слой размером в один символ :) Это было тестом, проверить, что правильно отрисовываю. В итоге, я отрисовываю в памяти, а потом при помощи DMA2D перегоняю в видео буфер в SDRAM.
  11. STM32H7, LTDC, FIFO underrun

    Это были бы "помехи" на время когда шина занята. С буфером в SDRAM так и происходит, если частоты памяти не хватает, то в моменты записи в нее на экране мусор. В данном случае, процессор к памяти не обращается, по крайней мере явно: while(1){}; 08000556 B 0x08000556 Да, есть еще код прерывания LTDC_ER_IRQHandler, там используется стек, но стек в DTCM расположен. Т.е. обращений к памяти нет. Я нашел в чем проблема. Видео буфер у меня был объявлен вот так: #define RAM_D1 __attribute__((section(".ram_d1"))) #define ALGN4 __attribute__ ((aligned (4))) volatile uint32_t RAM_D1 ALGN4 letter[32*1024/4]; Обратил внимание, что если я объявляю еще какую-то переменную, даже если не использую ее (оптимизация выключена), то начинаются проблемы. А если поменять объявление местами, чтобы видео буфер был с начала RAM_D1, а потом все остальное то работает. Думаю на этом месте уже понятно :) Я использовал выравнивание видео-буфера на границу 4 байт. Шина AXI 64 битная. Как только видео буфер получался не выровненным на 8 байт, сыпятся ошибки FIFO underrun. Сделал выравнивание, все заработало.
  12. STM32H7, LTDC, FIFO underrun

    Да, само собой, исправлю. Вообщем проблема вроде бы найдена, но решения пока нет. Потому что вынести все из RAM_D1 кроме видео буфера, это не решение. Кстати, если видео буфер перенести в пустой RAM_D2, то из него просто ничего не показывает и валятся ошибки FIFO. Должен же быть какой-то арбитраж или назначение приоритетов, чтобы из памяти и флеша мог не только CPU читать? У меня есть такая же плата, только вместо H743 запаян F429. И там отлично работает и из памяти и из флэша.
  13. STM32H7, LTDC, FIFO underrun

    В этом случае был бы мусор, а не FIFO underrun. По совету jcxz убрал из RAM_D1 вообще все. В тестовом проекте перенес секцию .data и .bss в DTCM. И заработало. Ошибок нет, отображается все верно. Разместил .data и .bss в RAM_D2 (там всего 32 байта), тоже работает без ошибок.
  14. STM32H7, LTDC, FIFO underrun

    Выложил пример кода https://github.com/Sergey1560/h7_ltdc
  15. STM32H7, LTDC, FIFO underrun

    Да частота 32Мгц. Пробовал опускать частоту до 9Мгц, экран начинает чуть заметно мерцать, но ошибки FIFO underrun все равно сыпятся. Ожидал, что могут быть проблемы с доступом к SDRAM (подключена по 16бит шине), но оттуда как раз два слоя 800*480 RGB565 показывает без проблем и ошибок. Попробую. Сейчас в RAM_D1 кода нет, кроме видеобуфера там несколько переменных лежит, но они не используются. Проект тестовый и МК стоит в бесконечном пустом цикле while(1}{} и ничего не делает. Т.е. вроде бы как к памяти обращаться ему незачем. Стек лежит в DTCM. И в целом, ситуация когда LTDC по 64-битной шине AXI на 240Мгц не успевает получить данные для вывода по 16бит на 30Мгц немного удивляет. Из SDRAM (16 бит, частота 120Мгц) то оно успевает все получить, даже когда отрисовывает 2 слоя одновременно.