Jump to content

    

sst78rus

Участник
  • Content Count

    34
  • 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. Благодарю. Убрал RDDI и заработало без defective.
  2. Я видимо что-то не понимаю. По ссылке на гитхаб, лежит бинарник с прошивкой от 8 марта 2020. В библиотеке JLink последняя версия для OB от 7 января 2019. При этом, если верить гитхабу, бинарник был залит 6 декабря 2017 года и больше изменений не было. И вообще последние изменения в там были 2 года назад. Кто-то похоже все таки сделал машину времени :) x893, благодарю, понял по поводу обновления.
  3. А откуда эта прошивка? С ней так же говорит про defective, но прошивка внутри от 8 марта 2020. JlinkConfig версии 6.86d имеет внутри прошивку от 7 января 2019.
  4. Да, клон. Извиняюсь, сразу не уточнил. На stm32f072c8t6 сделан. Фото показывать особо смысла нет, на плате только МК, 4 конденсатора, 2 резистора, светодиод и ams1117 :) Посмотрел по ссылке с предыдущей страницы, вроде бы "условия" выполнены - GDBFULL нет в списке лицензий, за серийным номером идет 0xFF. До недавнего обновления JLink-а работал без предупреждения о devective.
  5. Добрый день. Есть J-Link OB-STM32F072-CortexM, на последних версиях JLink стал писать, что он defective, хотя работать продолжает. Как оказалось, МК на нем не защищен от чтения, соответственно считал с него прошивку, исправил серийный номер на одну цифру (стоял не -1, а какой-то осмысленный) и залил обратно. Однако все равно Jlink считает его defective (исправленный серийник отображается верно). Не подскажете, на основании чего JLink определяет его как defective и можно ли это исправить в прошивке? Пока просто пропатчил библиотеку, чтобы убрать окно, но делать это после каждого обновления не хочется.
  6. Вот тут есть пример использования - https://www.youtube.com/watch?v=q4CxE5P6RUE&t=622s Я только не нашел как перенести "отладочную информацию" из гидры куда-нибдь в отладчик. Благодаря "псевдокоду" удобно разбирать что происходит и можно "переименовать" интересующие функции, добавить комментарии к коду и т.д. Но не всегда получается чисто статически разобраться, иногда удобнее в отладчике посмотреть. И вот было бы здорово или подключить отладчик интерактивно (так точно умеет IDA с x86 кодом), или хотя бы экспортировать комментарии в отладчик. Сейчас пользуюсь Ozone в качестве отладчика и во втором окне смотрю в гидре подсказки, что происходит. Код который разбираю был на С++ и много вызовов происходит очень не очевидно, без отладчика не понять куда будет переход.
  7. Про hal библиотеку я никак не смогу вам объяснить, я про нее ничего толком не знаю. По вашим словам получается, что у вас проблемы с dma2d? А если при помощи dma2d копировать не в sdram, а скажем в память мк? Только адрес буфера выровняйте по границе 4-х байт. Может проблема с sdram, но проявляется при интенсивной записи через dma?
  8. Да, раз артефакты есть в видеобуфере, то ltdc может и не иметь ошибок. Попробуйте локализовать проблему. Сначала сделайте рисование прямоугольника "руками" (всмысле просто записью значений в цикле в видеобуфер). Тут можно даже без экрана проверить - очищаем память, рисуем прямоугольник, читаем обратно и проверяем записанное. Если с "одиночной" записью проблем нет, попробуйте обычным DMA в режиме mem2mem. Т.е. как-то определить где у вас проблема - в работе с sdram, в настройках dma2d или еще где. Да, чтоб проще глазами поверять содержимое, можно сделать небольшим размер слоя. В идеальном варианте - чтобы ширина была такой, сколько у вас в окне отладчика помещается. Тогда просто сразу видно, что куда пишется. При ширине слоя в 1024 не очень удобно это смотреть :)
  9. Получается у вас отображается правильно, а в видеобуфере лежит с артефактами. Как вы буфер заполняете? И чтоб проще смотреть было, очистите буфер перед заполнением, и прямоугольник поменьше возьмите.
  10. Ну у ltdc два обработчика, LTDC_ER_IRQHandler и LTDC_IRQHandler. Соответственно ошибки в одном, а преревыния по номеру строки в другом.
  11. Просто на всякий случай: вы же знаете, что на ошибки у ltdc отдельный обработчик прерывания? Ну я так, на всякий случай, на что сам натыкался :) Да, и тут можно подобрать небольшую линию с артефактами и проверить,например в отладчике , что лежит у вас в видеобуфере. Т.е. где появляются артефакты - в выводе в видеобуфер или в ltdc.
  12. Вот пример с NoOS под F4 https://github.com/Sergey1560/stm32_systemview
  13. Конечно есть. Вы же читали тему, где я спрашивал о такой проблеме и там же выложил в чем проблема. В Вашей таблице видно, что проблем нет у линий которые начинаются с адреса кратного 4. У вас прерывание по ошибкам ltdc включено? Посмотрите, какие флаги взводятся при выводе линий с артефактами.
  14. Это как одна из версий, если есть проблемы при работе с DMA. При отключенном кэше mpu не нужен, будет и без него работать. Я просто сталкивался с интересными ошибками, когда данные в кэше лежат не сначала 32 битной строки и при сбросе кэша портились "соседние" данные. Хотя если вы hal используете, то там это учтено. Проверить это проще всего, выключив для теста кэш. А с выключенным кешем, вам и mpu не нужно, можно и его выключить на время теста. А без TouchGFX вывод работает? Ну и опять же, в качестве версии для проверки - а на самом деле, в том месте где у вас полосы, какой цвет лежит? Соответствует содержимое видеобуфера изображению?
  15. Кэш данных включен? Попробуйте выключить кэш и mpu.