>>21811084 The hole in the controller can't be fixed, and you can't buy a separate microchip on AliExpress. I also have a BL602 relay that I also burned out with my experiments, and they don't sell microchips for it either.
I think DR means "Dual Role" (wifi + bt), in which case it can be removed. Added it just for testing, and forgot to remove it.
0x40012034 is unknown, but it's also in RF_P0_BASE range.
With it, i've had no packet drops for 10 minutes (but there were some duplicates).
But i didn't test without it.
https://github.com/openshwprojects/OpenBK7231T_App/pull/1963 LN882H/LN8825 ADC, H UART (with configurable pins), H changing log port.
Disabled berry for now, added tuyamcu driver for testing. Plus i remember there was a request for BL0942 for H.
Fixed 8266 crash (https://github.com/NonPIayerCharacter/OpenBK7231T_App/blob/95316e3bf42fc9efae36a355138f15714977b51b/src/mqtt/new_mqtt.c#L2450)
Possibly https://github.com/openshwprojects/OpenBK7231T_App/pull/1969 Flash vars on BK and W600 in easyflash.
With this, every platform would support KV storage.
Moved fast connect data from config to EF.
Disabled log and asserts in EF so that it would be more compact.
Removed __FILE__ macro (would return empty string).
Disconnect from wifi on reboot/short sleep (possibly make it bk only). As it is now, first connect attempt after reboot/wake would fail with psk option.
All in all, + about 500 bytes to .rbl on 7238.
Very cool, certain merge, but just let me know - maybe we could easily use some kind of "create dropdown helper" to make it more DRY? We already have one for a button. Don't we have a dropdown helper somewhere?
However... it seems you're using fx_ syntax, not a generic dropdown?
>>21828358 Will survive, but only on new installs.
Plus, currently there is no way to disable them (via DISABLE_FLASH_VARS_VARS)
It might even be possible to enable HLW8112 together with BL09xx in the same build (flash vars conflict before?)
Would be good to test it on real 8112 device.
Easyflash holding flashvars on W600 would also allow enlarging config over the actual flashvars area so config V4+ would be possible without moving own flashvar structure.
Downgrade will loose data, since it's not aware of the changes.
But that was always the case (CRC over the whole V4 range will be different to the CRC over V3 config.)
The only thing i've noticed is that first boot is slower, probably because it's erasing env area.
What i tested: T, N, N_ALT and 8. If they work, then the rest will work too.
Plus new sdk always logs when it's switching flash protect on/off.
P.S i put flash vars at 0x1E5000, because on T1 there is some encrypted data at 0x1E4000, that looks similar to tuya config.
I tested the 1969 PR on N just now, all I have to say is - I can't figure out how to measure reboot time, it is that fast, will try to monitor the uart output to figure out what is going on....
as @p.kaczmarek2 said it feels like reboot is broken
>>21830400 Updated my N plug to 1.18.255. Works fine (at least for now).
But it started spamming Button_OnLongPressHold. It didn't on 1.18.247_ALT (at least i don't think so, i've had logging disabled).
Why would buttons behaviour change? Wasn't it untouched?
insmod wrote:
Disconnect from wifi on reboot/short sleep (possibly make it bk only). As it is now, first connect attempt after reboot/wake would fail with psk option.
.
@DeDaMrAz maybe that's what you mean by quick reboot? You mean... quick reconnect?
maybe that's what you mean by quick reboot? You mean... quick reconnect?
Not what I have seen, both reboot and reconnect worked and are quick, haven't seen failed WiFi reconnects... maybe I am wrong as my tests were short and I haven't observed the TX2 output I was more focused on other aspects, LFS, startup commands, last state.....
The discussion centers on flashing the LN882H (specifically LN882HKI) module using open-source tools and firmware such as OpenBeken and OpenBK7231T_App, with detailed guides and video tutorials available. Flashing involves grounding the BOOT pin and using UART communication, which employs ASCII commands and the YMODEM protocol for data transfer. Several tools have been developed and shared, including LN882Loader (Linux-based) and Windows GUI wrappers, with ongoing improvements to support faster flash reading and dumping via commands like "fdump." Users report challenges with UART adapters, power supply stability, and correct COM port usage, highlighting the importance of proper hardware setup (e.g., CH340G vs. FTDI232 UART adapters). SSDP support and Home Assistant integration are discussed, with SSDP requiring IGMP flag enabling and driver activation in firmware. GPIO pin behavior and limitations are examined, noting that certain pins (A13 to B2) are reserved for QSPI flash and should not be used as GPIO outputs. Firmware versions and SDK updates are tracked, with reverse engineering efforts revealing internal flash structures and configuration data. WiFi stability issues on LN882H modules are reported, potentially linked to power supply quality or environmental factors, distinct from BK7231N platform behavior. Pinout details for LN882HK1 modules are clarified, identifying UART TX and RX pins and the BOOT pin for flashing mode entry. Overall, the community collaborates on improving flashing tools, firmware features, and hardware understanding to enable cloud-free operation and integration with smart home systems. Summary generated by the language model.
