Jump to content

    

b-volkov

Свой
  • Content Count

    183
  • Joined

  • Last visited

Community Reputation

0 Обычный

About b-volkov

  • Rank
    Частый гость

Контакты

  • Сайт
    Array

Информация

  • Город
    Array

Recent Profile Visitors

2106 profile views
  1. Спасибо! В самом деле неправильно считывал ROM.
  2. Подходящую специализированную тему не нашел, по этому спрошу здесь, поскольку делаю на МК :) И так, надо подключить несколько DS18b20 к одной шине, а для этого нужен режим MATCH_ROM. Вроде бы все делаю по даташиту. 64-битный код предварительно считал командой READ_ROM и получил вполне правдоподобное значение. Потом дал команду MATCH_ROM, за ней передал полученные ранее 8 байт из ROM и затем команду чтения. Читаются все единицы, т.е. датчик не опознал код и не передал ни каких данных :(. Все перепроверил, записал посылку на осциллограф и разобрал ее побитно - все правильно. В режиме SKIP_ROM все работает нормально. Вот побайтнная последовательность: RESET 0x55 команда MATCH_ROM 0x28 1 байт 64-битного кода 0x2d 0xab 0x29 0x09 0x00 0x00 0x2e 8 байт 64-битного кода (CRC) 0xbe команда READ_RAM 0xff дальше читаются все единицы 0xff... Если кто работал с датчиком в этом режиме - помогите.
  3. Пробовал, не работает. Помогает, если до и после предполагаемой точки останова вписать соответственно __disable_irq() и __enable_irq(), но это каждый раз надо править код, если хочешь новый брекпоинт... Попробую поиграть с регистрами.
  4. Есть J--Link Segger купленный более 10 лет назад и, соответственно, не умеющий работать с новыми ядрами (в часности, Cortex M7). Есть шанс его перепрошить на что-то более свежее? Выхлоп JLink.exe: SEGGER J-Link Commander V6.84b (Compiled Sep 21 2020 14:47:39) DLL version V6.84b, compiled Sep 21 2020 14:46:07 Connecting to J-Link via USB...O.K. Firmware: J-Link ARM V8 compiled Nov 28 2014 13:44:46 Hardware version: V8.00
  5. Причина вроде бы понятна: эффект наблюдается только если во время остановки приходили какаи-либо прерывания (в моем случае работали таймера). Похоже, что после возврата из обработчика прерываний программа снова попадает на брекпоинт и останавливается. Вот только как с этим бороться - все равно не понятно.
  6. IAR 8.4 + STLink+STM32F7xx. Если остановить программу на брекпоинте, то она потом не может с него уйти, выполняешь "Go" или "Step" - остается в той же точке. Приходится снимать брекпоинт,делать шаг и потом брекпоинт восстанавливать . Если отлаживаешь циклический процесс с несколькими брекпоинтами, да еще в разных модулях, то полная вешалка. В чем может быть дело?
  7. Утилитка при запуске выдает "Error when opening device (error code 2)" Спасибо за присланные дампы, попробую выпаять EEPROM и зашить обычным программатором... Хуже все равно не будет :)
  8. Нашел у коллег USB-Blaster какого-то третьего производителя и считал от туда EEPROM. Разница оказалась в чипе FT245, у меня с буквой "В", у них с "R". Как и предполагал Zig, xml залить не удалось, пришлось вручную вбивать все поля. После программирования девайс стал определятся как "USB-Blaster", но с восклицательным знаком, т.е. драйвер его не узнавал. Попытка установить драйвер заново так же не увенчалась успехом. А самое интересно, теперь мой бластер не находится в FT Prog. Похоже, пора покупать новый бластер... Спасибо всем за ответы.
  9. Я не совсем понимаю, о чем идет речь и как это узнать :( Записать дефолтные значения в EEPROM получается, но там, видимо, надо ввести определенные значения всяких вендоров и ID, иначе драйвер не опознает железяку. Совершенно верно, там стоит МАХ3064, FT245BL, 93с46 и 245-й буфер. Фото сделал, но надписи на чипах плохо видно.
  10. Помогите, люди добрые! Сдуру стер EEPROM (93с46) у Terasic Blaster :( Конфигурировал свои платы на FT232H с помощью FTProg, а бластер то же был подключен, вот и попался под горячую руку... Если у кого есть этот девайс, не поленитесь слить с него содержимое 93c46 и пошлите его мне, плиз. Возможно, подойдет содержимое EEPROM и от альтеровского USB-бластера. Для этого нужна программа FTProg (https://www.ftdichip.com/Support/Utilities.htm#FT_PROG ) . Если кто не знает, как с ней работать, то порядок такой: 1. Подключаем бластер к USB. Желательно, что бы других устройств на USB не было (ну, кроме мышей и клав), они то же могут оказаться на чипах FTDI. 2. Запускаем FTProg и выполняем поиск устройств (DEVICE->Scan или F5). Будет найден бластер и отображено содержимое его EEPROM . Если все-таки найдется несколько устройств, то по полю Product Descriptor и Manufacturer можно понять, кто является бластером. 3. Кликаем правой кнопкой по найденному устройству и выбираем "Save As Template". 4. Посылаем сохраненный xml-файл мне ( b-volkov@yandex.ru) PS: Главное, не заходите в раздел программирования, а то то же будите искать содержимое EEPROM :)
  11. Win7. Драйвер установлен, в Диспетчере устройств бластер есть, но Quartus его не видит. Брандмауэр отключен. По одному из найденных в инете советов пробовал запускать jtag-сервер вручную (jtagserver.exe –install), но получил сообщение “Error opening SCM”. На КАЗУСе рекомендуют устанавливать драйвер бластера строго по инструкции альтеры: https://www.intel.com/content/www/us/en/programmable/support/support-resources/download/drivers/usb-blaster/dri-usb-blaster-vista.html, но у меня так не получается. Моя винда в принципе не выдает диалог «Найдено новое устройство», а сразу начинает поиск драйверов в интернете. Автоматический поиск я отключил, но диалог все равно не появляется, а сразу выдается сообщение, что драйвер не был установлен и в диспетчере появляется устройство с желтым восклицательным знаком. Таким образом, драйвер я могу поставить только через «Диспетчер устройств -> Обновление драйверов», а это не совсем по инструкции. Вопрос: в самом ли деле установка драйвера не по указанной инструкции может являться причиной моей проблемы? Если да, то буду икать, куда делся диалог «Найдено новое устройство». Или есть еще какие варианты? Самое главное, раньше я не раз ставил тот же самый Квартус с тем же бластером, и не помню, что бы были подобные проблемы…
  12. Совершенно с Вами согласен. Мало того, у меня уже есть реализация под другой камень своего простенького (если не сказать - примитивненького) UDP, которого вполне хватает для моих задач. Просто надумал освоить STM32F7, купил КИТ и вижу, что в комплекте уже готовый полноценный IP-стек. В принципе, не исключена ситуация, что когда-нибудь моему девайсу придется работать с какой либо сторонней софтиной или железякой, которые могут только по TCP. Вот и решил попробовать, не думал, что эта вещь такая капризная. Ну раз не получается с LwIP, тогда пойдем ниже. Тут уже писали ранее писали о глючности MAC-драйверов. Речь идет о HAL-драйвере эзернета? Как тогда быть? Самому писать?
  13. To: dimka76 UDP я пока не пробовал, хотелось бы с TCP разобраться... Ваш проект с FreeRTOS (или какой другой OS)? Просто я использую демку от IAR-STM32F746xx-SK которую сам переделывал под STM32F746-DISCOVERY. Эта не самая новая демка (main - файл датирован 14 годом)и, возможно, не самая "прямая", но это единственный проект, который я смог найти без FreeRTOS,которая мне на фиг не нужна. Родной пример для этого КИТа, увы, работает с RTOS, а "выпилить" ее мне ума не хватило, слишком глубоко она там засела. Мне TCP нужна исключительно для "получил/передал пакет" . По этому просьба: если у кого есть работающие примеры/проекты использования lwip БЕЗ всяких там осей - буду крайне признателен.
  14. Так я не выкидывал инициализацию стека, просто это не попало в листинг :) . Я выкинул только HTTP-сервер EthHandle.Instance = ETH; EthHandle.Init.AutoNegotiation = ETH_AUTONEGOTIATION_ENABLE; EthHandle.Init.Speed = ETH_SPEED_100M; EthHandle.Init.DuplexMode = ETH_MODE_FULLDUPLEX; EthHandle.Init.MACAddr = &macaddr[0]; EthHandle.Init.RxMode = ETH_RXPOLLING_MODE; EthHandle.Init.ChecksumMode = ETH_CHECKSUM_BY_HARDWARE; EthHandle.Init.MediaInterface = ETH_MEDIA_INTERFACE_RMII; EthHandle.Init.PhyAddress = 0; EthHandle.State = HAL_ETH_STATE_RESET; if (HAL_OK != HAL_ETH_Init(&EthHandle)) { printf("ETH init fail!\n"); while(1); } printf("ETH init OK.\n"); /* Initialize Tx Descriptors list: Chain Mode */ HAL_ETH_DMATxDescListInit(&EthHandle, DMATxDscrTab, &Tx_Buff[0][0], ETH_TXBUFNB); /* Initialize Rx Descriptors list: Chain Mode */ HAL_ETH_DMARxDescListInit(&EthHandle, DMARxDscrTab, &Rx_Buff[0][0], ETH_RXBUFNB); /* Initilaize the LwIP stack */ LwIP_Init(); Думаю, если бы МАС не был привязан к стеку, вообще бы ничего не работало. А тут просто непонятные задержки... А что именно Вы настраивали в стеке? У меня такое ощущение, что либо не те настройки, либо я чего-то не делаю в callback-функции.
  15. Пытаюсь разобраться с LwIP под STM32F7. За основу взята одна из демок Web-сервера без FreeRTOS. HTTP я выбросил, взяв от туда куски связанные с инициализацией LwIP. Задача - просто передать пакет пот TCP от компа в контроллер. Контроллер является сервером. Инициалицая, биндинг и соединение проходят (правда, не каждый раз, но это второй вопрос), а вот при получении пакета получается какая-то фигня: Контроллер получает пакет, но акнолидж почему-то не отправляет. Через пару секунд винда делает повторную посылку и тогда сразу отправляется два акнолиджа. Если отправлять большой кусок данных, то ситуация немного лучше: акнолидж на первый фрейм так-же не приходит, пока не будет повтора, а последующие подтверждаются примерно через 200мс. Но скорость как-то все-равно не айс: 100к за 5 секунд. Вот код инициализации и callback функции: /* Инициализация */ MyPCB = tcp_new(); tcp_setprio(MyPCB, 64); err = tcp_bind(MyPCB,IP_ADDR_ANY, 55); MyPCB = tcp_listen(MyPCB); tcp_arg(MyPCB, MyPCB); tcp_accept(MyPCB, MyTCPAccept); /* Main loop */ while (1) { LwIP_Pkt_Handle(); LwIP_Periodic_Handle(timeCounter); } } /*Callback фуккции*/ static err_t MyTCPAccept(void *arg, struct tcp_pcb *pcb, err_t err) { struct tcp_pcb_listen *lpcb = (struct tcp_pcb_listen*)arg; tcp_accepted(lpcb); tcp_setprio(pcb, 64); tcp_arg(pcb, 00); tcp_recv(pcb, MyTCPRecv); tcp_err(pcb, MyTCPErr); tcp_poll(pcb, 0, 4); tcp_sent(pcb, 0); return ERR_OK; } static err_t MyTCPRecv(void *arg, struct tcp_pcb *pcb, struct pbuf *p, err_t err) { printf ("Received %d\n",p->tot_len); tcp_recved(pcb, p->tot_len); pbuf_free(p); return ERR_OK; } static void MyTCPErr(void *arg, err_t err) { printf ("LWP_ERR: %d\n",err); } Что я не так делаю?