Ошибка при прошивке z03mmc.bin после промежуточной about z03mmc

[pvvx]

Есть ещё такое:
После смены прошивки с оф. на "кастом" требуется перезагрузить BT адаптер, а не термометр. Т.е. полностью комп.
BT адаптер и система запоминают все UUID устройства привязав их к MAC устройства и работают некорректно, пока не обновят данные.
В некоторых случаях, при разных драйверах BT адаптера, очень сложно заставить систему забыть старые данные, фиксированные по MAC устройства. В таких случаях помогает смена MAC устройства...
На Linux желательно стереть память о устройствах в '/var/lib/bluetooth/' ( - актуально для HA и Bluez).

---

Данная проблема связана со стандартом Bluetooth. Для экономии питания и времени связи BT адаптер обязан помнить таблицу UUID устройства (и многое другое), чтобы не перечитывать всё каждый сеанс соединения. При этом у устройства есть специальный типовой UUID, указывающий на изменения в этой таблице. Но устройство не может запоминать всех клиентов, кому уже было указано о смене конкретных UUID в своей таблице…
И реализации этих фич у всех разные...
Chrome эксплорер тоже помнит все данные о BT устройствах. Требуется полная перезагрузка эксплорера (закрытие всех сеансов/окон). Удаление всех привязок в системном меню, плюс, если BT адаптер в USB - выдернуть и вставить. Иначе - полная перезагрузка компа с отключением питания адаптера.
С Zigbee всё ещё сложнее – по этому у него не будет стандартных реализаций на уровне ОС (для всеобщего использования).

На сегодня отставание в реализации поддержки Bluetooth/BLE у Linux, в сравнении с Android - более 10 лет.
У Windows – лет на 5. iOS сама по себе и там стандарты не писаны – выдумывают что хотят - свою "отсебятину".

[pvvx]

Где вы берете такие старые термометры - Hardware Revision String: B1.5 (производились более двух лет назад)?
B1.5 наверно имеет самое большое потребление из всех из-за своего набора микросхем.

Идущие с ними батарейки наверно уже сели от старости и неправильных условий хранения (некоторые CR2032 просто умирают в ноль при перевозке зимой по России).

The version is determined by the addresses of the display and sensor on I2C

HW	LCD I2C addr	SHTxxx I2C addr	Note
B1.4	0x3C	0x70 (SHTC3)
B1.5	UART!	0x70 (SHTC3)
B1.6	UART!	0x44 (SHT4x)
B1.7	0x3C	0x44 (SHT4x)	Test original string HW
B1.9	0x3E	0x44 (SHT4x)
B2.0	0x3C	0x44 (SHT4x)	Test original string HW

Version 1.7 or 2.0 is determined at first run by reading the HW line written in Flash.
Display matrices or controllers are different for all versions, except B1.7 = B2.0.

[devbis]

Версия платы написана на самой плате, со стороны экрана

[booroondook-eng]

Попробуйте выполнить эту операцию не на ПК, а на смартфоне (только не забудьте файл прошивки предварительно поместить на смартфон). Все точно так же - через браузер Chrome.

[pvvx]

Тут может влиять проблема, если ранее была зашита прошивка Zigbee. Она устанавливает защиту записи на Flash и OTA в область нулевых адресов Flash и штатным SDK Telink OTA невозможна.
Тогда OTA отработает один раз, при загрузке в верхнюю область Flash, а последующая OTA будет невозможна, т.к. нулевой регион был защищен от записи прошивкой Zigbee...

Прошивки термометров из https://github.com/pvvx/ATC_MiThermometer/ по старту очищают флаги защиты Flash:
https://github.com/pvvx/ATC_MiThermometer/blob/master/src/app.c#L555

Поведение остальных – мне неизвестно.
Если возникла именно такая ситуация, тогда потребуется программатор.
В варианте Windows USB-COM Flasher с версии v0.3 снятие защиты записи Flash уже встроено. Срабатывает старте при заливки fw.
Для https://github.com/pvvx/TLSRPGM/blob/main/TlsrPgm.py потребуется использовать команду fsw 0.

[kachalovmg]

Датчики оба новые, только из коробки. Третий лежит ждёт.
Попробую с телефона, может что то с блютуз ноута его не устраивает. На спрутаи видел человека с такой же ошибкой.

[kachalovmg]

Перезагрузка ноутбука, очистка кеша chrome не помогла, прошивка с другого устройства, так же нет результата.

#20
Это видел вчера, но честно говоря не знаю что делать с этой информацией. Насколько я понял, проблема большого файла решается промежуточной прошивкой, но видимо не без проблем как в моём случае.

[zzz676]

Где вы берете такие старые термометры - Hardware Revision String: B1.5 (производились более двух лет назад)? B1.5 наверно имеет самое большое потребление из всех из-за своего набора микросхем.

Идущие с ними батарейки наверно уже сели от старости и неправильных условий хранения (некоторые CR2032 просто умирают в ноль при перевозке зимой по России).

The version is determined by the addresses of the display and sensor on I2C

HW LCD I2C addr SHTxxx I2C addr Note
B1.4 0x3C 0x70 (SHTC3)  
B1.5 UART! 0x70 (SHTC3)  
B1.6 UART! 0x44 (SHT4x)  
B1.7 0x3C 0x44 (SHT4x) Test original string HW
B1.9 0x3E 0x44 (SHT4x)  
B2.0 0x3C 0x44 (SHT4x) Test original string HW
Version 1.7 or 2.0 is determined at first run by reading the HW line written in Flash. Display matrices or controllers are different for all versions, except B1.7 = B2.0.

А после прошивки в zigbee версию можно HW как то посмотреть? Где берем - работали) у меня несколько 20 года датчиков - там вроде B1.4, несколько B1.6

[zzz676]

Где вы берете такие старые термометры - Hardware Revision String: B1.5 (производились более двух лет назад)? B1.5 наверно имеет самое большое потребление из всех из-за своего набора микросхем.

Идущие с ними батарейки наверно уже сели от старости и неправильных условий хранения (некоторые CR2032 просто умирают в ноль при перевозке зимой по России).

The version is determined by the addresses of the display and sensor on I2C

HW LCD I2C addr SHTxxx I2C addr Note
B1.4 0x3C 0x70 (SHTC3)  
B1.5 UART! 0x70 (SHTC3)  
B1.6 UART! 0x44 (SHT4x)  
B1.7 0x3C 0x44 (SHT4x) Test original string HW
B1.9 0x3E 0x44 (SHT4x)  
B2.0 0x3C 0x44 (SHT4x) Test original string HW
Version 1.7 or 2.0 is determined at first run by reading the HW line written in Flash. Display matrices or controllers are different for all versions, except B1.7 = B2.0.

Кстати Сегодня пришли 2 новых термометра. Оба версии 1.5. Дата производства 10.2022 .

[pvvx]

Кстати Сегодня пришли 2 новых термометра. Оба версии 1.5. Дата производства 10.2022 .

Это скорее всего дата упаковки. Сенсор SHTC3 уже давно не производится. Чип, заменяющий контроллер LCD в B1.5 и B1.6, устанавливался какой-то временный (похоже на какой-то MCU со своей программой и управляемый по UART), т.к. было время искусственно созданного "дефицита чипов".
Сенсоры влажности имеют свойство деградировать со временем...

[IvanGavrilenko]

Версия платы написана на самой плате, со стороны экрана

Подскажите прошивал через UART и похоже оторвал резиновый шлейф от дисплея - теперь ничего не показывается (а может криво прошилось и не стартует плата) - вопрос не сталкивались ли с таким и как можно локализовать проблему (например померить на контрольных точках) ?

И мог ли я спалить плату если перепутал 3v3 и землю?

[devbis]

Резинка не приклеена, просто прижимается платой и корпусом к экрану. С ней ничего не случится

Переполюсовка могла повредить чип, я не проверял:)

Если дело в прошивке, надо прошить еще раз на более низкой скорости или дополнительно стереть флешку

[IvanGavrilenko]

Переполюсовка могла повредить чип, я не проверял:)

А есть вариант проверить жива ли плата простыми действиями (вроде если дать на плату 3v3 то между gnd и 14 точкой должно быть 3v3) или нет и проще сохранить корпус этого термометра как памятник кривым ручкам?

или дополнительно стереть флешку

Я правильно понял что для этого запустить скрипт с ключом 'ea' вместо 'wf'?

[devbis]

Я, к сожалению не знаю как можно проверить живость чипа, кроме как прошить и получить результат.

Да, еа стирает флешку

[psike01]

Попробовал седня прошить по 2 датчика с Hardware Revision String: B1.4 и Hardware Revision String: B1.6.
С 1.4 прошились без проблем, с 1.6 не хотят. Выходит ошибка
NotSupportedError: GATT operation failed for unknown reason.

Так что ошибка явно связана с ревизией датчика, а не действиями пользователя

[devbis]

Я тестировал только на 1.4, у меня она в наличии. Там отличие только в экране должно быть. Интересно, поможет ли в этих случаях прошивка с выключенным экраном.

[booroondook-eng]

Я несколько раз и прошивал с выключенным (вернее, с отсоединенным) экраном, и спаривал. Более того - даже без батарейки (питание 3.3 В шло от USB-адаптера). По сути голая плата на трех проводках болталась. И всё работало.

[pvvx]

Так что ошибка явно связана с ревизией датчика, а не действиями пользователя

Ошибка связана с промежуточной прошивкой от devbis без исходников и уточнить что там происходит нет никаких возможностей. Только гадать.

И данная прошивка не выдает никаких идентификаторов, чтобы отличить её от стандартной. Это создает путаницу и не дает возможностей даже пробовать создать любые исправления в TelinkMiFlasher.

[devbis]

Прошивка совпадает с pvvx/atc_mithermometer 4.4 с добавлением перемещения прошивки по адресу 0x40000 и изменением
bls_ota_set_fwSize_and_fwBootAddr(200, 0x40000);
при старте

Вот полный патч, но это первая рабочая версия, и я на ней остановился.
ota_40000.patch

[pvvx]

Следующее гадание, на основе лога:

20:42:53: Update error: NotSupportedError: GATT operation failed for unknown reason.
20:42:53: Disconnected.

говорит о том, что происходит разрыв связи. Причина может быть в элементарном нарушении таймингов BLE.
Скорее всего в прошивку вписана какая-то процедура, которая выполняется более нескольких мкс не позаботившись о таймингах BLE, например стирание сектора или секторов Flash....

[pvvx]

Прошивка совпадает с pvvx/atc_mithermometer 4.4 с добавлением перемещения прошивки по адресу 0x40000 и изменением bls_ota_set_fwSize_and_fwBootAddr(200, 0x40000); при старте

Вот полный патч, но это первая рабочая версия, и я на ней остановился. ota_40000.patch

Область Flash, куда записывается OTA для Zigbee 0x40000+ используется для сохранения логов замеров (названа memo).
Функция OTA в SDK не очищает область на ходу, куда записывается новый OTA.
Очистка области для OTA в SDK производится только при старте, да с частичной проверкой на "пустоту" сектора путем проверки первых байт на 0xff.

Функции, включаемые по USE_EXT_OTA, производят стирание области Flash для OTA, пытаясь согласовать задержки стирания секторов Flash с таймингом соединения BLE. Это поддерживается в TelinkMiFlasher только для MJWSD05MMC вызовом специальных специфических функций предустановок и предупреждением пользователя о стирании MEMO и прочей информации без которой будет не восстановить работу термометра в MiHome....

У MJWSD05MMC батарейка мощнее и выдерживает более длительную активную работу SoC со стиранием подряд пачки секторов Flash с одновременным сохранением связи соединения и конденсатор в цепи питания у MJWSD05MMC больше, что обеспечивает большую стабильность. У "безконденсаторных" термометров при импульсах провала питания первым сбивается таймер в SoC, что убивает тайминг связи...
Соответственно это:

-	bls_ota_setTimeout(16 * 1000000); // set OTA timeout  16 seconds
+	bls_ota_setTimeout(120 * 1000000);

никак не поможет - в BLE связь прыгает по каналам с согласованным таймингом и если разошлись - конец соединению...

---

Необходимо сделать специальную “промежуточную” прошивку, которая должна:

1. Использовать random MAC – снимет множественные проблемы на стороне адаптера и ОС у пользователей
2. Должна быть специальная поддержка со стороны программы для эксплорера.

---

К примеру, нет никакой возможности определить прошивку atc1441, т.к. она не имеет ни одного идентификатора и по этой причине не обслуживается в TelinkMiFlasher, что создает проблемы у пользователей...

[kachalovmg]

pvvx, спасибо за альтернативный прошивальщик #50
Прошил с помощью него датчик, который оставался новым. Первые два, с описанной здесь проблемой, прошитые промежуточной, не получилось.
Есть ли возможность откатиться с промежуточной, что бы в дальнейшем прошиться, альтернативным прошивальщиком. Не знаю как правильно это сделать.

[pvvx]

Не знаю как правильно это сделать.

Если в датчик уже записана ATC_ota_400000, тогда только путем аппаратной перепрошивки (проводами).

Можно попробовать, если ещё работает ATC_ota_400000, перед самой перепошивкой нажать
. Но уверенности, что это поможет - нет. Я не использовал и не тестировал ATC_ota_400000 от devbis.

[kachalovmg]

pvvx
Да, ATC_ota_400000 работает, но !Delete all records! не помогло, заказал USB/ttl.
Спасибо.

[pvvx]

@kachalovmg - Для выяснения ситуации есть просьба:
Запустите DebugFlashRead.html.
Соединитесь с термометром, впишите 40000, затем Read, потом скопируйте сюда, что выйдет в последней строке лога:

[kachalovmg]

в последней строке лога:

040000:2680000000005D024B4E4C54270788008680

[pvvx]

040000:2680000000005D024B4E4C54270788008680

Значит там сама прошивка сидит.
Тогда нужно смотреть ещё адрес 0 и 0x20000

[kachalovmg]

Тогда нужно смотреть ещё адрес 0 и 0x20000

Адрес 0
000000:FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
Адрес 0х2000
002000:FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
Это означает пусто, я полагаю.

[pvvx]

Это означает пусто, я полагаю.

Да. Это значит, что вероятнее всего просто сбой связи из-за срыва таймингов BLE какой-то длинной процедурой.
Но возможно, что дальше что-то прописано, тогда OTA из SDK срывается. Она не проверяет на чистоту всю область записи и не стирает сектора, а проверяет только начало сектора и с неким шагом в секторе, и если в середине что записано, то при записи новой прошивки накроется на этом месте, проверив что записалось не то.
Т.е. вам грозит аппаратная перепрошивка и не стоит пользоваться ATC_ota_400000 от devbis, т.к. уже есть другие варианты.

[IvanGavrilenko]

кроме как прошить и получить результат

Да действительно после очистки с помощью python TLSR825xComFlasher.py -p COM9 -t5000 ea и заново прошивки ошибка ушла и датчик прошился нормально.

Огромное спасибо за помощь

[devbis]

I received V1.6 HW sensors and confirm that OTA is broken.
After some research I found out that enabling uart breaks the ability to use OTA on transitional firmware.
For this case I just disable LCD for 1.5/1.6 revisions in transitional fw, now update works correctly.
For already stuck devices the only known way is to flash via UART/SWS.