Jump to content

    

jcxz

Свой
  • Content Count

    10772
  • Joined

  • Last visited

Everything posted by jcxz


  1. Видимо всё-таки - со сбросом. Без сброса не получилось. Ну так а какой у него должен быть статус если ваш отладчик его остановил? Пошагать по инструкциям. Если шагается - значит подключиться без сброса вам не удалось. Тогда шагать дальше и искать где стопорится.
  2. Так и полльте в периодическом прерывании. Как уже правильно сказали: процесс стирания/записи - очень медленный. Так, что даже если поллить на 100Гц, то потерянным на излишнем ожидании временем (<=.01 сек) - наверняка можно пренебречь.
  3. Видимо просто Ваш комп - на вражеском процессоре, да и операционка тож поди - не православная. Вот бесы то из неё и полезли, нарушая работу православного сервиса.
  4. Это сильный довод в пользу версии бага в коде или в схеме (питании и т.п.), и не в пользу версии о помехах. Приобретите испытательный генератор. Который специально предназначен для испытаний на ЭМС. И формирует гарантированные тестовые воздействия на устройство. А все эти пинания колёс с пылесосами - бесполезная затея. типа такого: https://www.samarapribor.ru/main/igje_15-2a.html
  5. в datasheet F407 только об input говорится: ...и ничего об output. в мануале F4 стрелка только в одну сторону:
  6. Вроде в мануале ничего нет про "выход". А только "input". POR никто не отменял. Сброс должен произойти по POR. А кроме того - программа дополнительно сможет правильно диагностировать источник сброса: сигнал сброса или проблема с питанием.
  7. Вам - сложно, мне - нет. Диод не моргать может например по той причине, что где-то в ПО (из-за бага) нога, управляющая этим диодом, была переведена в состояние INPUT или OK (если зажигание диода происходит 0). Тогда сброс WDT будет происходить, а мырг - нет.
  8. Если зависание происходит не из-за программного бага, а например - из-за помехи, и внутренний WDT не спасает (по каким-то причинам), то программно тут ничего не исправить, как ни костыльте. Тут только - исправлять схемотехнику платы (устойчивость к помехам) + ставить внешний WDT. А если зависание - из-за программного бага, то не костылить надо, а этот самый баг искать и исправлять. И как дополнительный пункт: нормально разобраться как именно функционирует встроенный WDT. Найти и почитать мануал на МК. А не полагаться на "средства esp-idf". Возможно, что может быть можно изменить источник тактирования WDT (если есть возможность) или ещё какие опции его работы.
  9. Не факт. Диод может "перестать мигать" например из-за того, что длительность импульса сильно уменьшилась и Вы глазом его уже не видите, а для сброса WDT - вполне хватает. Или из-за того, что что-то случилось в вашей программе, она стала выдавать импульс сброса WDT в другом месте (где нет зажигания диода). Или (не знаю про какой WDT речь - внешний или внутренний), но внутренний WDT - опять же может быть или отключен программой (если есть такая возможность) или не включен при старте (если был сброс, а потом сразу зависание, ещё до момента запуска WDT). Если же речь про внешний WDT, отключаемый высокоомным состоянием на WDI, то возможно программа перевела пин в Z-состояние, а в схеме нет внешней подтяжки к "0" или "1". Или ещё 100500 причин.... В серьёзных устройствах обязательно ставят внешний WDT (не отключаемый) + внутренний. Плюс - желательно оконные (с контролем процедуры/сигнала сброса). У Вас так сделано? Или только внутренний?
  10. Ну значит - проблема не из-за "слишком частых GPIO-прерываний", а в чём-то другом. WDT не спасёт от программных багов. Он главным образом для тех случаев, когда какое-то внешнее воздействие (помеха) привела к порче содержимого памяти/регистров и соответственно - нарушению хода программы.
  11. Это элементарно решается программно - грамотной обработкой этих прерываний: в ISR запрещаем прерывание от ноги; запускаем таймер на выдержку интервала гашения дребезга (с прерыванием в конце); в ISR таймерного прерывания выключаем таймер и заново разрешаем прерывание от ноги. Всё. И без всяких аппаратных костылей. Про работу NVIC - читайте мануал на ядро Cortex-M.
  12. В самом первом сообщении ТС писал: т.е. - вроде не STM32. Или....... неужто Куб уже и до SiLabs-а добрался??! PS: Вроде как оба EFM32GG332, EFM32GG380 - это Cortex-M3 (without FPU). И в то же время в присланном исходнике имеется такой "перл": void GLCD_VBandClear (unsigned NUM, unsigned x0,unsigned y0,unsigned x1,unsigned y1) { unsigned dx,dy,ddx; unsigned xx0,xx1; unsigned i,m; GLCD_Direction (USE_HORIZONTAL); dx = (unsigned)fabs(x1-x0); dy = (unsigned)fabs(y1-y0); ... Зачем-то(?) использована плавучка, там где вообще нафиг не нужна. Уж не говоря о том, что на Cortex-M3 будет программная эмуляция (тормоза), так ещё и возможны проблемы с ошибками округления на операциях unsigned->float->unsigned. И, соответственно - неверная работа функции. Автор сего творения просто на ровном месте разложил потенциальные грабли. Быдлокод детектед?
  13. Похоже это вы издеваетесь. Или троллите.... Видимо я слепой.... Укажите номер строки, начиная с которой эта функция якобы находится в том, что вы прислали. Подайте жалобу в комитет защиты ёжиков...
  14. А как прикажете быть, если нужна малопотребляющая система, большую часть времени проводящая во сне, лишь изредка выходящая на связь? Ведь для такой системы обычно выбирают какой-нить слабенький МК, возможно вообще без USB. А тут ещё и host городить.... Уж не говоря о том, что ещё и 5V надо создать, которые кроме как для этого USB больше и не нужны никому в этой системе.
  15. Если не делаете, то может всё-таки стоит делать? По присланному огрызку кода невозможно понять - правильно ли работаете с SPI, так как самой работы с SPI (функция USART_SpiTransfer()) там нет. Так что - продолжаем гадать на кофейной гуще... Но мнение о том, что проблема именно в кривой прошивке - укрепилось.
  16. Я смотрю: GLCD_WR_REG(0x11); //Exit Sleep GLCD_WR_REG(0x29); //Display on Вы проигнорировали мой совет по необходимым задержкам: как и требования даташита ILI934x, в котором говорится о необходимости задержек. Возможно из-за этого и не работает у Вас.
  17. Ну вроде как очевидно это: Опсосы прекрасно знают, что у модемов потребление инета - значительно выше (в среднем). И видимо из статистики они знают, что в тех тарифах (где есть какой-то бесплатный или дешёвый трафик) если они воткнуты в телефон, этот объём трафика расходуется далеко не полностью. У модема же будет гораздо больший % использования трафика включённого в тариф. Это не выгодно опсосу.
  18. Задержки, о которых я писал, даже близко не могут быть достигнуты тем снижением частоты SCLK, которое производил ТС. И без программы - тоже. Так как баг может быть программным.
  19. В моём проекте на ILI9340 при инициализации только в 2-х местах есть задержки: после "Software Reset" (0x01) = 6 мсек и после "Sleep Out" (0x11) = 121 мсек. Больше нигде нету. Весь инит идёт нормально на любой SCLK (вплоть до 45МГц пробовал). Хотя конечно не ILI9341.
  20. И что? Что изменилось? программа = прошивка.
  21. Ну вот оно и есть: А вы сомневались....