logo elektroda
logo elektroda
X
logo elektroda

Exploring A9 Minicam Variation: XF16 PB380EA6341 MCU, T25S80 SPI Flash, XR872, Skylark SDK

divadiow 8352 192
ADVERTISEMENT
  • #151 21531057
    divadiow
    Level 34  
    divadiow wrote:
    curious about how the pins will work with XF16 being QFN68 and XR872AT being QFN52 and XR872ET being QFN40. We don't have a datasheet for XF16 yet.


    because of this though. QFN68

    Added after 3 [minutes]:

    dumping stuff here as I find btw
    https://github.com/divadiow/DataSheets/tree/main/GalaxyCore
    https://github.com/divadiow/DataSheets/tree/main/AllWinner_Xradiotech
  • ADVERTISEMENT
  • #152 21531066
    p.kaczmarek2
    Moderator Smart Home
    So we have some camera datasheets. But wait for a moment.

    It seems that I have some UART flashing issues again. Can you triple-check if it works still as expected for you, with OpenXR?

    I am starting to think that SOMEHOW latest OpenXR872 release has flashing via UART broken.
    Helpful post? Buy me a coffee.
  • #153 21531075
    divadiow
    Level 34  
    I was flashing OK last night and now latest release is flashing too
    PhoenixMC software interface showing firmware flashing process to a device on COM72 port, progress bar at 42%.

    Added after 3 [minutes]:

    make a new cable/dev thing with spare USB-TTL adaptor and 5v out?

    Added after 6 [minutes]:

    wait.

    Added after 2 [minutes]:

    subsequent flash attempts since OpenXR872_1.18.94.img

    Screenshot of PhoenixMC software showing synchronization error during firmware upgrade via COM72 port.
  • #154 21531095
    p.kaczmarek2
    Moderator Smart Home
    So this commit breaks futher UART flashing on XR872?
    Screen fragment showing configuration file changes with removal of the OTA section from image_cfg/image.cfg.
    https://github.com/openshwprojects/OpenXR872/...e17921e7e6845f234d9b861f8e77874e352cdb269345f
    That's the same commit that allowed our image to boot on 1MB flash chips.
    Helpful post? Buy me a coffee.
  • #155 21531099
    divadiow
    Level 34  
    hmm. so why could I flash after this non-GH build if that was the only change in code? https://www.elektroda.com/rtvforum/topic4074636-120.html#21530564

    Added after 14 [minutes]:

    have you a 2mb flash cam readily available that you can program with OpenXR872_1.18.94.img to see if flash size makes any difference? i'm not sure what that would prove exactly though
  • #156 21531105
    p.kaczmarek2
    Moderator Smart Home
    The camera I use for testing has 2MB flash, but I tried 1MB flash yesterday and it was the same. Maybe I should edit that config to put OTA somewhere within 1MB bounds instead of removing it entirely.

    Added after 2 [hours] 23 [minutes]:

    Done:
    
    {
        "magic": "AWIH",
        "version": "0.4",
        "OTA": {
            "addr": "880K",
            "size": "4K"
        },
        "image": { "max_size": "880K" },
        "count": 6,
        "section": [
    

    Can you check?
    Helpful post? Buy me a coffee.
  • #157 21531260
    divadiow
    Level 34  
    Yes, flashed that to a still-working XF16, so I didn't have to bother unsoldering yet if it didn't work, boots OK but sadly no flashes after that to same build or any other :(

    Screenshot of PhoenixMC software during firmware flashing, showing a synchronization error.

    Code: Text
    Log in, to see the code


    Added after 34 [minutes]:

    there must be some code thing to allow uart commands to be received and actioned to put it into download mode and the XR872 code currently is set to not allow this?
  • #158 21531300
    p.kaczmarek2
    Moderator Smart Home
    So, you are 100% sure that version before this commit allows UART flashing:
    https://github.com/openshwprojects/OpenBK7231...mmit/0274993d7fc077c4f160556c932c98428e7c3cc1
    and versions after this commit do not?

    So, to sum up.
    First version that we got to work - with this section:
    
    {
        "magic": "AWIH",
        "version": "0.4",
        "OTA": {
            "addr": "1024K",
            "size": "4K"
        },
        "image": { "max_size": "880K" },
        "count": 6,
        "section": [
    

    On 1MB chip, it does not boot, but it boots on my custom 2MB flash chip.
    However, on 1MB chip, it still allows UART recovery?

    Second version (introduced here https://github.com/openshwprojects/OpenBK7231...mmit/0274993d7fc077c4f160556c932c98428e7c3cc1 ) - with this section removed:
    
    {
        "magic": "AWIH",
        "version": "0.4",
        "image": { "max_size": "880K" },
        "count": 6,
        "section": [
    

    It boots on both 1MB and 2MB chips, but does not allow UART flash.

    Third version (the one I added in attachment):
    
    {
        "magic": "AWIH",
        "version": "0.4",
        "OTA": {
            "addr": "880K",
            "size": "4K"
        },
        "image": { "max_size": "880K" },
    

    It also boots on both 1MB and 2MB chips, but does not allow UART flash?
    Helpful post? Buy me a coffee.
  • #159 21531310
    divadiow
    Level 34  
    I'd need to flash again to be 100% sure. I appear to have lost track of what worked when and on what. I currently have 2 1mb cams that boot but no UART flash ability and 1 2mb cam that doesn't boot into anything and won't allow UART flash either. If I desolder to flash again, I guess I could flash A9 factory then we're open for UART to anything from that point.

    Added after 45 [minutes]:

    OK. I have two 1mb cams that I can do uart with now. In case you've already gone further with your own testing, is there anything specific you want me to flash right now?

    Added after 40 [minutes]:

    I have flashed 1.18.93 to both 1mb cams (2mb isnt behaving at the moment) and neither boot (as we know) but both can be communicated with in PhoenixMC again after flash
  • #160 21531400
    p.kaczmarek2
    Moderator Smart Home
    Ok fresh tests on 2MB:
    
    SPI ID: C84015
    ---------------------------------------------------------------------------
    Currently selected:  GD25Q16x [3.3V] 16 Mbits, 2 Mbytes
    ---------------------------------------------------------------------------
    

    I flashed original backup via SPI (desoldered chip), then I flashed 1.18.93 via UART. Then flashed 1.18.93 via UART again. Then power off and power on, then I am not able to flash via UART anymore.
    So... 1.18.93 still has the problem?

    Attempt 2. I restored original backup via SPI (desoldered chip), then I flashed 1.18.94 via UART. Then flashed 1.18.94 via UART again. Then flashed 1.18.94 via UART again. Then flashed 1.18.94 via UART again. Then flashed 1.18.93 via UART. Then flashed 1.18.94 via UART. Then power off and power on, then I am not able to flash via UART anymore.

    Attempt 3. I restored original backup via SPI (desoldered chip), then I flashed 1.18.90 via UART. And again. Then power off and power on, then I am not able to flash via UART anymore.

    Conclusion so far: all previous tests were more or less incorrect. It seems that something that allows UART flashing is persistent in RAM until power off. So the UART problem started earlier or it was present from the start.
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #161 21531407
    divadiow
    Level 34  
    to confuse things a little, I am flashing 1.18.93 over and over uart to 1mb flash and removing all power from device in between

    Added after 9 [minutes]:

    is your experience different because with a 2mb flash you are booting into the app and response to commands from uart are ignored because this ability is disabled in code? whereas with no boot, ie not getting past bootloader, on 1mb flash, the BL still allows UART comms?

    what I mean is, regardless of flash size, is the issue that something needs changing in the SDK to allow commands from uart to be received to put device into uart download mode?
  • #162 21531421
    p.kaczmarek2
    Moderator Smart Home
    Let's check this build:
    
    #79 21523387  18 Apr 2025 18:16 https://www.elektroda.com/rtvforum/viewtopic.php?p=21523387#21523387
    

    Flashed factory firmware via desoldered flash chip. Flashed this build via UART. It boots:
    A RealTerm program window displaying yellow diagnostic messages related to TCP_server thread creation errors.
    UART is ok. I can flash again. And again.
    Wireless signal icon next to the text OpenXR872_000000000.
    Now power off... and on.
    Part of a software window with a greyed-out set buf button and the message Open comm OK !.
    Well, this version seems to allow UART even after power off and on cycle? That's very strange? That would suggest that something between 18 Apr and the XR872 addition to online builds has changed?

    I've flashed XR872 at_demo build now locally and lost again ability to flash via UART.

    Could the culprit be here?
    https://github.com/openshwprojects/OpenXR872/commits/main/
    Update image.cfg or FIX FLASH CONFIG SAVE?
    Helpful post? Buy me a coffee.
  • #163 21531440
    divadiow
    Level 34  
    1 mo. I *may* have found something. Is it possible that we need OTA module defined (right word?) even if we're not doing actual OTA.

    Screenshot of documentation showing a section from localconfig.mk configuration with xplayer, XIP, and OTA options in Chinese and English.

    Looking at XR872development_manual.pdf it seems there's another program pictured - iflymod - where a "jyd ota..." command is sent and it looks like it's sending this over UART.

    dunno, just a thought

    Screenshot from the XR872 Chinese manual showing instructions and iflymod program window with commands related to firmware upload via UART.
  • #164 21531441
    p.kaczmarek2
    Moderator Smart Home
    I've put obk in "hello_ world" project and I believe this is enabled there, but you can double check:
    https://github.com/openshwprojects/OpenXR872/...in/project/demo/hello_demo/gcc/localconfig.mk
    https://github.com/openshwprojects/OpenXR872/blob/main/project/demo/hello_demo/prj_config.h

    Added after 5 [minutes]:

    Degraded back SDK to version from 8 days ago:
    Screenshot from GitHub showing the commit history of the OpenXR872 project with the Make mkimage executable commit highlighted.
    Still nothing. Here's another idea - maybe logging printf blocks UART? That "every second" stuff?
    Next test incoming...
    Helpful post? Buy me a coffee.
  • #165 21531566
    divadiow
    Level 34  
    p.kaczmarek2 wrote:
    I've put obk in "hello_ world" project and I believe this is enabled there, but you can double check:

    double-check = flash original hello_world binary?

    p.kaczmarek2 wrote:
    Next test incoming...

    how's it going?
  • #166 21532842
    divadiow
    Level 34  
    Code: Text
    Log in, to see the code


    is present in localconfig.mk but not in prj_config.h
  • Helpful post
    #167 21534886
    divadiow
    Level 34  
    if you sniff out the UART comms as PhoenixMC opens com and sends reboot/download mode command:

    gif
    Screenshot of a Chinese firmware upgrade tool showing a synchronization error on COM port.

    Code: Text
    Log in, to see the code


    5x 10 sets of U until timeout




    with a receptive firmware the device will acknowledge with this response

    gif
    Firmware upgrade software showing a synchronization error while uploading a .img file.

    Code: Text
    Log in, to see the code


    https://github.com/search?q=repo%3Aopenshwprojects%2FOpenXR872+BROM&type=code

    so, https://github.com/openshwprojects/OpenXR872/blob/main/project/common/cmd/cmd_upgrade.c ?

    Code: C / C++
    Log in, to see the code


    Added after 8 [hours] 50 [minutes]:

    p.kaczmarek2 wrote:
    maybe logging printf blocks UART? That "every second" stuff?


    on this, if you set loglevel 0 then PhoenixMC takes longer to error, like it's getting to send full 5x 10 'U' and getting no response. With higher logging you get a quicker synchron error return, presumably because it sends the first 10 Us but with a more chatty uart it gets the wrong response

    Screenshot of a terminal with system logs, the upgrade command, and repeated U characters.
  • ADVERTISEMENT
  • #169 21536627
    p.kaczmarek2
    Moderator Smart Home
    Hey, can you check whether flashing old OpenXR809 also breaks uart download mode without grounding required pins?

    Added after 6 [minutes]:

    So you think this code prints that "OK"? The one which is send by XR872 back to flasher?
    Code: C / C++
    Log in, to see the code

    Well, you may be right:
    Screenshot of C code from OpenXR872's cmd_util.c file, showing status description arrays and a function returning command status descriptions.
    So we have reboot command for firmware update and just classic reboot?
    Code: C / C++
    Log in, to see the code

    that would mean that we need to run cmd_upgrade_exec, but where is it called from?
    https://github.com/search?q=repo%3Aopenshwpro...%2FOpenXR872%20cmd_upgrade_exec&type=code
    QR code demo has command "upgrade":
    Screenshot of a code editor showing the definition of a command array in the command.c file from an OpenXR872-based project.
    Which matches what XR tool sends, wow, it seems you've really find it! I guess we need to add this command for OBK now? Or... do we even build with AT commands on?
    Helpful post? Buy me a coffee.
  • #170 21536637
    divadiow
    Level 34  
    yeh baby! :D

    I did a search too in the Tuya XR806 SDK to see where such references might pop up in demos
    Screenshot of a code editor showing a search for the term “upgrade” in Tuya XR806 SDK files.

    I started to try something but it doesn't work and I guess with what you've added, more is required

    https://github.com/openshwprojects/OpenBK7231...:OpenBK7231T_App:refs/heads/xr809_cmd_upgrade
    https://github.com/openshwprojects/OpenXR809/...are/master...divadiow:OpenXR809:cmd_upgrade.c
  • #171 21536653
    p.kaczmarek2
    Moderator Smart Home
    Maybe you don't need to add more. It seems it's already in hello_demo, which I used as container for OBK, due to the lack of time:
    A code snippet in command.c listing command registrations including mem, heap, thread, and upgrade.
    https://github.com/openshwprojects/OpenXR872/...6418953/project/demo/hello_demo/command.c#L89
    but it doesn't change the fact that it does not recognize those commands yet, so something must be missing. Maybe removed by accident.
    This is the entry point:
    https://github.com/openshwprojects/OpenXR872/...8023bf76418953/project/demo/hello_demo/main.c
    Well, but it only has platform_init call, the original hello_demo has it as well:
    https://github.com/divadiow/xr872_sdk/blob/dev/project/demo/hello_demo/main.c
    |So we probably need a compile time switch that enables AT commands. CONFIG_something

    Added after 1 [minutes]:

    If you look for main_cmd_exec in the SDK, you can find line 666:
    Screenshot from GitHub editor showing code in platform_init.c file. The macro PRJCONF_CONSOLE_EN and assignment cparam.cmd_exec main_cmd_exec are underlined at line 666.
    Helpful post? Buy me a coffee.
  • #173 21536783
    p.kaczmarek2
    Moderator Smart Home
    Very good, you have solved the problem! Is it tested well, with power off and on cycles? Then I can merge.

    This only leaves one question - why it worked with new firmware before power off/on cycle?
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #174 21536793
    divadiow
    Level 34  
    p.kaczmarek2 wrote:
    Is it tested well, with power off and on cycles?

    yes. Camera unplugged and re-plugged fresh a few times.

    p.kaczmarek2 wrote:
    why it worked with new firmware before power off/on cycle?

    hmm. I can't think why really. Anything to do with reset options selected here in settings?

    Software settings window for firmware programming with highlighted Restart after programming and Hardware location burning mode options.

    that "hardware location burning mode" translation is a little bit wrong. I have seen it referred to as "Hardware reset burning mode" in a couple of PDFs or guides. for example:

    Code: Text
    Log in, to see the code

    https://zhuanlan.zhihu.com/p/694447378

    PhoenixMC settings window with the hardware reset burning mode option highlighted and checked.

    I should probably replace pictures in posts with correction

    Added after 5 [minutes]:

    also confirming that "reboot" button from the debug menu also works after successful com open in PhoenixMC
  • #175 21536798
    p.kaczmarek2
    Moderator Smart Home
    I have merged your changes. Now, doesn't the same work for XR806 and XR809?
    Helpful post? Buy me a coffee.
  • #176 21536807
    divadiow
    Level 34  
    cool.

    I started on XR809 but was getting all my branches mixed up so shifted to XR872 only.
    https://github.com/openshwprojects/OpenBK7231T_App/actions/runs/14788805529/job/41522009963

    if enabled it complains about:

    Code: Text
    Log in, to see the code


    and with command.h added it complains about partition overlap https://github.com/openshwprojects/OpenBK7231T_App/actions/runs/14789021450/job/41522592014

    but maybe this was the point I mixed something up. I anticipated starting again with XR809
  • #177 21536815
    p.kaczmarek2
    Moderator Smart Home
    Probably you did good, but it just enabled so many commands that it ran out of flash memory. What kind of command.c source code did you use? I think we just need that upgrade and reboot command. We do not need full AT command line.
    Helpful post? Buy me a coffee.
  • #178 21536820
    divadiow
    Level 34  
    https://github.com/openshwprojects/OpenXR809/commit/731618ff67c61b88b9981acfe0768a5f84b6cdac

    maybe from https://github.com/openshwprojects/OpenXR809/tree/master/project/wlan_demo - can't actually remember now!

    there's also the potential to save 7-9k with newer toolchain on XR809 but I haven't tested anything but build https://github.com/openshwprojects/OpenBK7231T_App/pull/1619
  • #179 21536893
    p.kaczmarek2
    Moderator Smart Home
    I'd remove all commands except update and upgrade.
    Helpful post? Buy me a coffee.

Topic summary

The discussion revolves around a variation of the A9 minicam featuring the XF16 PB380EA6341 MCU and T25S80 SPI Flash. The user shares insights on the firmware and hardware components, noting that the flash chip is an 8mbit model. There are mentions of difficulties in identifying the SPI ID C74014 using Flashrom, NeoProgrammer, and ASProgrammer, with some success in dumping the firmware. Additional posts highlight network activity, including the camera reaching out to specific IPs, and provide links to related resources and sample video captures.
Summary generated by the language model.
ADVERTISEMENT