logd32
Солнце 29 октября 2017 г. 16:04
Привет,
Я все еще сталкиваюсь с проблемами во время загрузки под OSX (10.11.6), чтобы убедиться, что это не вызвано предыдущими изменениями в Core или Bootloader, я использовал текущие файлы Core и Bootlader из GitHub и загрузил уже скомпилированный универсальный PC13 BooloAderer. Я тестировал с помощью платы «синие таблетки» (модифицирован с 1.5K Res).
После загрузки первого эскиза (с использованием PB14 для остановки в режиме вечного загрузчика) у меня есть последовательный порт, тестовый эскиз работает.
Когда я загружаю, плата сбрасывается, загрузчик запускается (быстро мигает), DFU распознает ее, так как она не бросает ошибку сразу, однако через несколько секунд он жалуется «нет устройства DFU» и не загружает.
В конце концов, после долгого поживания с временем сброса в сценарии или нажатием кнопки сброса «в нужное время», я могу заставить его загрузить один раз, но частота отказов все еще более 95%.
Я нашел процедуру, которая работает в 100% случаев:
-Подключить плату с PB14 Low
-Установите PB14 High после загрузки.
-загрузить
-Установить PB14 Low
-сбросить доску
Таким образом это всегда работает. Таким образом, что -то на OSX приводит к выходу из строя нормальной процедуры загрузки, я подозреваю, что это связано с тем, как сброс выпускается перед поднятой.
Теперь мне интересно, есть ли способ заменить PB14 на флаг (EX в регистре RTC), флаг, который можно установить true перед загрузкой dfu_. Является ли это возможным? Есть ли способ установить этот флаг из USB или что Bootlaoder распознает сброс, выданный USB?
У меня есть вспомогательный вопрос, касающийся сброса/запуска после загрузки, я заметил, что плата никогда не сбрасывается и не работает должным образом после загрузки DFU, ее нужно сбросить вручную.
Я попытался заменить SystemHardreset (); (После dfufinishupload ();) с помощью некоторого светодиодного мигания, и я вижу, что эта точка достигается, я также проверил, что Systemhardreset (); работает нормально.
Итак, что может привести к остановке STM32 вместо сброса после dfu_upload? Я не понимаю, что он проблема.
Спасибо
Я все еще сталкиваюсь с проблемами во время загрузки под OSX (10.11.6), чтобы убедиться, что это не вызвано предыдущими изменениями в Core или Bootloader, я использовал текущие файлы Core и Bootlader из GitHub и загрузил уже скомпилированный универсальный PC13 BooloAderer. Я тестировал с помощью платы «синие таблетки» (модифицирован с 1.5K Res).
После загрузки первого эскиза (с использованием PB14 для остановки в режиме вечного загрузчика) у меня есть последовательный порт, тестовый эскиз работает.
Когда я загружаю, плата сбрасывается, загрузчик запускается (быстро мигает), DFU распознает ее, так как она не бросает ошибку сразу, однако через несколько секунд он жалуется «нет устройства DFU» и не загружает.
В конце концов, после долгого поживания с временем сброса в сценарии или нажатием кнопки сброса «в нужное время», я могу заставить его загрузить один раз, но частота отказов все еще более 95%.
Я нашел процедуру, которая работает в 100% случаев:
-Подключить плату с PB14 Low
-Установите PB14 High после загрузки.
-загрузить
-Установить PB14 Low
-сбросить доску
Таким образом это всегда работает. Таким образом, что -то на OSX приводит к выходу из строя нормальной процедуры загрузки, я подозреваю, что это связано с тем, как сброс выпускается перед поднятой.
Теперь мне интересно, есть ли способ заменить PB14 на флаг (EX в регистре RTC), флаг, который можно установить true перед загрузкой dfu_. Является ли это возможным? Есть ли способ установить этот флаг из USB или что Bootlaoder распознает сброс, выданный USB?
У меня есть вспомогательный вопрос, касающийся сброса/запуска после загрузки, я заметил, что плата никогда не сбрасывается и не работает должным образом после загрузки DFU, ее нужно сбросить вручную.
Я попытался заменить SystemHardreset (); (После dfufinishupload ();) с помощью некоторого светодиодного мигания, и я вижу, что эта точка достигается, я также проверил, что Systemhardreset (); работает нормально.
Итак, что может привести к остановке STM32 вместо сброса после dfu_upload? Я не понимаю, что он проблема.
Спасибо
Деван
Солнце 29 октября 2017 г., 17:06
В загрузчике есть некоторая поддержка, которая заставила его остаться в режиме загрузчика после сброса IDE. Смотрите это Тема форума на фоне.
Обратите внимание, что хотя загрузчик поддерживает его, ядро STM32DUINO должно записаться в регистр RTC, чтобы активировать его при сбросе платы.
Если вы хотите попробовать это, вы можете застрять вокруг Rxhook в STM32F1/cores/maple/usb_serial.CPP и добавьте этот код, чтобы установить флаг RTC, прежде чем сбросить плату.
Обратите внимание, что хотя загрузчик поддерживает его, ядро STM32DUINO должно записаться в регистр RTC, чтобы активировать его при сбросе платы.
Если вы хотите попробовать это, вы можете застрять вокруг Rxhook в STM32F1/cores/maple/usb_serial.CPP и добавьте этот код, чтобы установить флаг RTC, прежде чем сбросить плату.
bkp_init();
bkp_enable_writes();
bkp_write(10, 0x424C);
bkp_disable_writes();
Rogerclark
Солнце 29 октября 2017 г. 9:59 вечера
Спасибо @devan
Я действительно хотел добавить это в ядро, но сообщество, казалось, неохотно принимало это (хотя я не могу вспомнить, почему)
Я действительно хотел добавить это в ядро, но сообщество, казалось, неохотно принимало это (хотя я не могу вспомнить, почему)
logd32
Солнце 29 октября 2017 г. 22:14
Спасибо за возвращение.
Я только что проверил, его Rock Solid, наконец, я не использую RTC Backup Register, но я проверяю непосредственные регистры RCC_FLAG на загрузке, чтобы увидеть, что такое источник сброса. Флаг устанавливается соответственно, тогда оператор устанавливает флаг no_user_jump true, если источник сброса является программное обеспечение.
Этот метод никогда не удается, и он, вероятно, может обрабатывать вариации времени различных систем. Я могу понять, что некоторые пользователи могут полагаться на сброс программного обеспечения для своих вещей, но этот случай будет легко обработан путем отключения этого меканизма, если немного установлен в резервном регистре, уже используемой Bootlader (10) для установки Bootlader в вечную модель из программного обеспечения.
В любом случае, теперь успех загрузки на 100% на моем OSX против 5% до.
Не.Беременный. Сбросить и запустить после того, как загрузка теперь работает нормально, я добавил только несколько светодиодных стробов после Dfufinishupload, так что не уверен, почему она не удалась ранее.
Я только что проверил, его Rock Solid, наконец, я не использую RTC Backup Register, но я проверяю непосредственные регистры RCC_FLAG на загрузке, чтобы увидеть, что такое источник сброса. Флаг устанавливается соответственно, тогда оператор устанавливает флаг no_user_jump true, если источник сброса является программное обеспечение.
Этот метод никогда не удается, и он, вероятно, может обрабатывать вариации времени различных систем. Я могу понять, что некоторые пользователи могут полагаться на сброс программного обеспечения для своих вещей, но этот случай будет легко обработан путем отключения этого меканизма, если немного установлен в резервном регистре, уже используемой Bootlader (10) для установки Bootlader в вечную модель из программного обеспечения.
В любом случае, теперь успех загрузки на 100% на моем OSX против 5% до.
Не.Беременный. Сбросить и запустить после того, как загрузка теперь работает нормально, я добавил только несколько светодиодных стробов после Dfufinishupload, так что не уверен, почему она не удалась ранее.
Rogerclark
Пн 30 октября 2017 г. 12:34
Прохладный
Ханьязу
Пн 30 октября 2017 г. 12:55
[logd32 - Солнце 29 октября 2017 г. 16:04] - У меня есть вспомогательный вопрос, касающийся сброса/запуска после загрузки, я заметил, что плата никогда не сбрасывается и не работает должным образом после загрузки DFU, ее нужно сбросить вручную.Вы уверены, что SystemHardreset () будет вызван после dfufinishupload ()? Более новая Mac OS (El Capitan или позже) и Libusb не могут выпустить USB -сброс автобуса, даже если вы вызываете Libusb_Device_Reset (). SystemHardreset () не называет мой Mac и Blupill на самом деле. Пожалуйста, обратитесь к этим сообщениям.
Я попытался заменить SystemHardreset (); (После dfufinishupload ();) с помощью некоторого светодиодного мигания, и я вижу, что эта точка достигается, я также проверил, что Systemhardreset (); работает нормально.
Итак, что может привести к остановке STM32 вместо сброса после dfu_upload? Я не понимаю, что он проблема.
Спасибо
[libusb] libusb_reset_device не работает на Mac OS X 10.11 Эль Капитан
https: // sourceforge.net/p/libusb/mailma ... /34744234/
OS X El Capitan и его отказ сбросить USB -устройства
https: // www.Belle-Aurore.com/mike/2016/ ... B-Devices/
Есть какой -то патч, который будет изменять Libusb, чтобы называть usbdevicereEnumerate () вместо этого. Но патч, кажется, отвергается сообществом, и у последних либусбов все еще есть проблема.
Я сделал патч для загрузчика, который будет называть SystemHardReset () после некоторого тайм -аута, чтобы решить эту проблему. Пожалуйста, смотрите:
https: // github.com/hanyazou/stm32duino- ... F39316BBF0
И есть еще одна проблема с загрузкой/сбросом DFU,
https: // github.com/rogerclarkmelbourne/ ... 2/pull/297
Я выпускник, если вы попробуете эти модификации и сообщите о результате здесь (или там), потому что я действительно хочу решить эту проблему загрузки/сброса на Mac.
Ханьязу
Пн 30 октября 2017 г. 13:00
Я могу загрузить мигание.Ино эскиз на плату STM32 с моими модификациями.
Вам не нужно нажимать кнопку сброса. Пожалуйста, смотрите это видео.
https: // www.YouTube.com/watch?v = b_igpvzi7hu
Вам не нужно нажимать кнопку сброса. Пожалуйста, смотрите это видео.
https: // www.YouTube.com/watch?v = b_igpvzi7hu
logd32
Пн 30 октября 2017 г., 19:34
[Ханьязу - Пн 30 октября 2017 г. 12:55] - Вы уверены, что SystemHardreset () будет вызван после dfufinishupload ()? Более новая Mac OS (El Capitan или позже) и Libusb не могут выпустить USB -сброс автобуса, даже если вы вызываете Libusb_Device_Reset (). SystemHardreset () не называет мой Mac и Blupill на самом деле. Пожалуйста, обратитесь к этим сообщениям.Да, я отключил петлю NOP в dfufinishupload () и добавил немного светодиодного морга. Я 10.11.6 И я также могу подтвердить сброс от хоста, выпущенного «upload_reset», действительно работает нормально.
Я посмотрю на вашу модификацию и посмотрю, работает ли она здесь, в любом случае, как я сказал, что исправление, сделанное вчера, работает на 100%, загрузка, как и должно Сейчас он такой же надежный, как и любая доска Arduino, по крайней мере, на OSX1 10.11.6.
logd32
Пн 30 октября 2017 г., 19:44
[Ханьязу - Пн 30 октября 2017 г. 12:55] - Я выпускник, если вы попробуете эти модификации и сообщите о результате здесь (или там), потому что я действительно хочу решить эту проблему загрузки/сброса на Mac.Учитывая, что плата, которую вы делаете, кажется довольно большой, почему бы не использовать надлежащую, уже доказанную схему USB -сброса напрямую?
Патч на usbdevicereEnumerate () Изменение системы OSX не является вариантом.
logd32
Пн 30 октября 2017 г., 19:59
[Ханьязу - Пн 30 октября 2017 г. 13:00] - Я могу загрузить мигание.Ино эскиз на плату STM32 с моими модификациями.Я только что попробовал ваш патч, он работает для первой загрузки, но сбое при следующей загрузке.
Вам не нужно нажимать кнопку сброса. Пожалуйста, смотрите это видео.
https: // www.YouTube.com/watch?v = b_igpvzi7hu
Ханьязу
Пт, 03 ноября 2017 г., 21:57
[logd32 - Солнце 29 октября 2017 г. 22:14] - В любом случае, теперь успех загрузки на 100% на моем OSX против 5% до.Не могли бы вы поделиться исходным кодом загрузчика ?
Не.Беременный. Сбросить и запустить после того, как загрузка теперь работает нормально, я добавил только несколько светодиодных стробов после Dfufinishupload, так что не уверен, почему она не удалась ранее.
Я хотел бы знать, работает ли это на моем Mac.
SystemHardreset () не будет вызван, в то время как dfufinishupload () будет вызвана в конце загрузки в моей среде. И я вижу, что никто не выпустил USB -сброс в автобусе моим логическим анализатором.