Jump to content

    

sst78rus

Участник
  • Content Count

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