logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

[Youtube] LN882H module pinout and setup for flashing - step by step video guide

p.kaczmarek2 8151 175
ADVERTISEMENT
Report a violation of the law
Reply Cool? Ranking DIY | New topic
Notify about new articles
📢 Listen (AI):
  • #151 21609102
    insmod
    Level 29  
    >>21609082
    I changed it, because it dumps everything. And flash size is read just before dumping.

    Read everything into memorystream and then return specified offset?
  • ADVERTISEMENT
  • #152 21609114
    divadiow
    Level 36  
    p.kaczmarek2 wrote:
    We still probably need a "read at offset"

    I must admit, read from and write to specific offsets and custom lengths is often useful, though not a priority or a problem if not an option.
  • #153 21609140
    insmod
    Level 29  
    Just now got a terminal version working.
    fdump doesn't work there though
    Code: text Expand Select all Copy to clipboard
    Opening port COM6...
Port COM6 open!
upload_ram_loader will upload ramcode_ln882h.bin!
Sync with LN882H... wait 5 seconds
send version... wait for:  Mar 14 2021/00:23:32
Mar 14 2021/00:23:32
Connect to bootloader...
Will send file via YModem
YModem::send: v2 will wait for CRC...
YModem::send: v2 wait_for_next CRC ok!
YModem::send: first packet 01 00 FF 72 61 6D 63 6F 64 65 5F 6C 6E 38 38 32 68 2E 62 69 6E 00 31 35 30 30 38 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 79 7A
YModem::send: v2 will wait for ACK...
YModem::send: v2 wait_for_next ACK ok!
YModem::send: v2 will wait for second CRC...
YModem::send: v2 wait_for_next second CRC ok!
Sending at 0... Sending at 1024... Sending at 2048... Sending at 3072... Sending at 4096... Sending at 5120... Sending at 6144... Sending at 7168... Sending at 8192... Sending at 9216... Sending at 10240... Sending at 11264... Sending at 12288... Sending at 13312... Sending at 14336... Sending at 15008... Done!
YModem::send: sending loop done!
Start program. Wait 5 seconds
send version... wait for:  RAMCODE
version
RAMCODE
flash uid:0x433032313333342E3030230050009AFF
Give command: version
version
RAMCODE

[Timeout waiting for device reply]
Give command: version
version
RAMCODE

[Timeout waiting for device reply]
Give command: fdump 0x0 0x1000
fdump 0x0 0x1000
pppp

[Timeout waiting for device reply]
Give command: fdump 0x0 0x100
fdump 0x0 0x100
pppp

[Timeout waiting for device reply]
Give command:
  • #154 21609499
    divadiow
    Level 36  
    v22
    Dumps
    115200 - 184.0506484s
    460800 - 47.5169445s
    921600 - 24.772409s
    1500000 - 184.050883s

    Code: Text
    Log in, to see the code


    had to keep A9 low now because post-dump reset would bring up AP and a few bytes would change in between dumps
    brb the rest of tests

    Added after 3 [hours] 4 [minutes]:

    erase
    Code: Text
    Log in, to see the code

    [Youtube] LN882H module pinout and setup for flashing - step by step video guide

    write to blank (write fixed at 921600?)
    Code: Text
    Log in, to see the code


    OpenLN AP comes up as normal

    Added after 8 [minutes]:

    flash of Tuya backup to erased flash

    Code: Text
    Log in, to see the code


    SmartLife AP seen and pairs in Tuya app.
  • ADVERTISEMENT
  • #155 21609680
    insmod
    Level 29  
    I managed to create a terminal version with fast dumping, but changing the baudrate in code doesn't work for some reason. If changed manually in terminal, it works fine.
    Binary attached. Protocol is the same, 512 bytes of flash + 2 bytes crc.
    fdump [addr] [size]
    Delay before read output is about 2 seconds
    Writing/erase should work as well.
    https://github.com/NonPIayerCharacter/OpenLN882H/tree/_ramcode
    Attachments:
  • #156 21610045
    p.kaczmarek2
    Moderator Smart Home  
    I see you changed ISR to polling, is polling faster in this case?
    Helpful post? Buy me a coffee.
  • #157 21610067
    insmod
    Level 29  
    >>21610045
    Not faster, but more stable at higher baud rates.
    Remember how i complained about crc errors at 921600 and higher? This fixed that.

    Added after 2 [hours] 15 [minutes]:

    Surprisingly, merge with latest commit was very easy, only 2 conflicts (one of them was because of static ip change, another is translation).
    Attachments:
  • #158 21610212
    divadiow
    Level 36  
    insmod wrote:
    Surprisingly, merge with latest commit was very easy, only 2 conflicts (one of them was because of static ip change, another is translation).

    amaze.
    I wonder if this will make any diff to these reports of wifi issues.
  • #159 21610252
    p.kaczmarek2
    Moderator Smart Home  
    What did they change with SDK update?
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #161 21610273
    insmod
    Level 29  
    [postid:7bfc69fcbe][/postid:7bfc69fcbe]
    Nothing really major. We had v2.1_rc1, this one is v2.1_rc5.
    Wifi libs update, pvPortRealloc, pwm demo update (perhaps it will be possible to use original driver, instead of my reimplementation) etc.
    Plus i enabled -Os, so binary should be lighter.

    In v2.1_rc2 "Enhance the robustness of WiFi retransmission in extreme interference environment"

    It still need to be tested. Or if it even boots. I enabled test commands in https://github.com/openshwprojects/OpenBK7231T_App/pull/1724
  • #163 21610275
    insmod
    Level 29  
    [postid:f4387a6116][/postid:f4387a6116]
    We don't "have" ADC in OBK.
    In code, we use ADC channel 0. The one used for internal temperature and wifi calibration. For everything.

    Added after 12 [minutes]:

    It boots. Version is 1724_merge_a7d75940edc4
    All tests are successful.
    I remember there was a problem with long startup command? I wonder if it fixed now.
  • ADVERTISEMENT
  • #164 21610914
    divadiow
    Level 36  
    insmod wrote:
    I remember there was a problem with long startup command? I wonder if it fixed now

    Vaguely rings a bell but I may be thinking of most recent experience with long DS18B20 full driver startup command before @max4elektroda revised to make shorter. I will check maximum length when home
  • #165 21612107
    p.kaczmarek2
    Moderator Smart Home  
    Ok, is that Ln882H PR tested and ready?

    Also, I am preparing for release of our LN882H util, so I can move to adding it to Easy Flasher, but I have one question - @insmod how did you find out which offset has baud rate at the build RAM code? Did you just search for constant in bin code, did you decompile it with Ghidra, or is Keil creating some kind of link/debug file?
    Helpful post? Buy me a coffee.
  • #166 21612112
    insmod
    Level 29  
    >>21612107
    It was a self-compiled binary.
    I then simply recompiled it with a different baud rate and then ran compare in hex editor.

    No tests on PR were run, other that it simply boots and connects to wifi.

    Binary in https://www.elektroda.com/rtvforum/topic4096854-150.html#21609680 is different, it uses a normal terminal interface, but adapted to dump raw. Meaning it can dump at offset, variable baud rate, read and write without reset etc.
    But, i encountered a problem with changing baud rate in tool. Tool hanged. If baud rate is changed in terminal, it worked fine.
  • #168 21612221
    p.kaczmarek2
    Moderator Smart Home  
    Well, as long as OTA still works, we can still fix any potential problems if they arise...

    LN882H new flash tool summary (with great flash read by @insmod) drops tomorrow, and I will start integration with Easy Flasher later.
    Helpful post? Buy me a coffee.
  • #169 21612226
    divadiow
    Level 36  
    awesome. yes. I am flashing back and forth between general release and PR

    Code: Text
    Log in, to see the code

  • #170 21612759
    p.kaczmarek2
    Moderator Smart Home  
    Progress update, report, and new discussion topic - for clarity...
    https://www.elektroda.com/rtvforum/topic4131077.html
    Helpful post? Buy me a coffee.
  • #171 21614194
    divadiow
    Level 36  
    Code: Text
    Log in, to see the code

    The big 1.18.122 release is where LN882H AP mode after flashing does this;

    Code: Text
    Log in, to see the code


    it stops when you join AP but then device reboots. Subsequent AP is fine and you can configure as normal to STA

    Added after 2 [minutes]:

    it is not seen in the newer SDK PR

    Code: Text
    Log in, to see the code


    Added after 8 [hours] 42 [minutes]:


    sadly no change to LN882H WPA3 connectivity with SDK/wifi libs update

    Code: Text
    Log in, to see the code


    Added after 4 [hours] 8 [minutes]:

    [postid:247c78e621][/postid:247c78e621]
    https://gitee.com/lightningsemi/ln882h/commit/a813e6bc9577052993603b3f97c5dc971e1f3669
    Code: Text
    Log in, to see the code
  • #172 21615030
    insmod
    Level 29  
    Check WPA3 with latest update (and will wpa2 continue to work)
    And if it reconnects without problems
  • #173 21615134
    divadiow
    Level 36  
    ok. firstly, initial boot:

    Code: Text
    Log in, to see the code


    Success joining WPA-SAE (CCMP) AP
    Code: Text
    Log in, to see the code


    When AP is disabled, disconnecting OpenLN, LN constantly scans and displays all nearby APs over and over. Upon AP re-enable it connects again very quickly.

    Network UI showing connection details to AP OBK3 by device LN882H_STA.lan

    In WPA2-only and then in WPA2/WPA3 the behaviour is the same for successful connection and then scanning and re-connect after AP disappears.

    Feels like a big success.
  • #174 21709638
    sergiopoverony
    Level 5  
    Hi everyone, can anyone build an OTA firmware LN882H with SHT31X driver support?
  • #175 21709798
    max4elektroda
    Level 21  
    There are several ways to answer your question with: "Yes, you" ;-)

    If you have all development requiremnts on your PC, you only need to clone the repository,
    Then change "src/obk_config.h" to contain
    "#define ENABLE_DRIVER_SHT3X 1"
    under
    "#elif PLATFORM_LN882H"

    "make OpenLN882H" will then build it.


    If you don't have the needed environment, but a git account, you, can "build it online", if not, you can after you made an account ;-)
    The simplest way is to do it as laid out here:
    https://www.elektroda.com/rtvforum/topic4082682.html#21275413
    In the lower part after it shows an easy way to do "online Builds" in your own repository - no need for an PR in the OpenBeken repository.

    Fork the git and make your own branch
    Make sure, on "Action" tab, you allow workflows:
    Assuming this is your first approach, you will need to activate "workflows" once:
    So open "your" fork and as the very first step go to the "Actions" tab.
    If you read: "Workflows aren’t being run on this forked repository":
    Allow workflows with the button "I understand my workflows, go ahead and enable them".

    In your branch, as above, change "obk_config.h" to contain
    "#define ENABLE_DRIVER_SHT3X 1"
    under
    "#elif PLATFORM_LN882H"

    and commit the change.

    Under Actions tab wait until LN882H is built, then go to "summary" and download the firmware.


    Or, even simpler, let someone do it for you and take the firmware attached ;-)
    Attachments:
  • #176 21709801
    sergiopoverony
    Level 5  
    sergiopoverony wrote:
    Hi everyone, can anyone build an OTA firmware LN882H with SHT31X driver support?

    Thanks, I'm still learning the auto-assembly system and I don't understand anything yet.
Reply Cool? Ranking DIY | New topic
Notify about new articles
📢 Listen (AI):
Report a violation of the law

Topic summary

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.
Popular Topics
ADVERTISEMENT