Hi @Lazar-Demin & @crispyoz, I was able to find the root cause for this issue. I've created a pull request in OnionIoT/source github repository with the fix.

@crispyoz, I am sorry to hear that you are still experiencing the consequences of your accident, and I wish you a smooth and speedy recovery.

Given your active presence in the forum, I had assumed you were part of Onion. I sincerely appreciate the clarity and proactivity you bring to each of your contributions.

The dissolution of Onion comes as a surprise to me, as one of the key factors in validating our design with the Omega was the assurance of production until 2028. May I ask if you know what will happen with ongoing production, or if another company has acquired the IP and continues to support the design?

Thank you once again for your valuable support and contributions.

Hi @crispyoz and @Zheng-Han, I wanted to kindly follow up and ask if you have any updates regarding this issue.

Due to compliance with cybersecurity standards, we are required to update the OpenWrt version in our Zigbee gateways equipped with Onion devices. This makes the matter critical for us, and we would highly appreciate any feedback or guidance you can provide.

In the absence of updates and/or a solution, we may need to reassess our roadmap and start evaluating alternative SoM solutions for future developments.

Best regards,
Matias

Ok, thanks @crispyoz. If either you or @Zheng-Han happen to test it, please keep me posted. Also, if there is any further question, don't hesitate in asking me.

Best regards,
Matias

@crispyoz I’m so sorry to hear about your accident, and I wish you a smooth and full recovery.

Thanks for pointing out to that document. I went through it, and I have some questions and/or comments:

1. First of all, I'm using an Omega2Pro board. I understand that circuitry build around Q2 and Q1 FETs is intended to comply with this requirement for HW_RST_N since it removes power from the SPI flash memory when the reset pulse is issued.
2. Regarding the GPIO6 & GPIO11 HW_RST_N requirements, there is no external circuitry in the Omega2Pro board to comply with it. However, as mentioned in the bullet above, with old firmware versions, the SoC can be reset through the HW reset line.
3. Is it possible for you to program an Omega2Pro with the firmware based on OpenWrt v23.05.3 (e.g. onion_omega2p-23.05.3-20250709.bin) and confirm you are getting the same device behavior?

UPDATE: I think that this information might also be important for this issue. When forcing a kernel panic (with command echo c >> /proc/sysrq-trigger), the device behavior is the same than the one observed with the HW_RST_N line: it works on old firmware, but not with the new one.

Best regards,
Matias

Hi @crispyoz, just wanted to check if you get my last response and also if you have any further questions.
This issue is becoming critical in my development.

Best regards,
Matias

@crispyoz my bad, I should have been more specific.

After issuing the reset pulse, the device becomes 'unresponsive', meaning that it can't be accessed via SSH, it does not respond to ping commands, and if I'm connected over serial, I don't even see the echo to the input characters.

If I power-cycle the device, meaning I power it off and on, it boots normally. It is NOT necessary to run through any recovery process (e.g. u-boot, web recovery, etc).

Thank you for your assistance.

Hi @crispyoz! Thanks for taking care.

I understand that factory reset via the reset button interacts with 'SW_RST' line (aka GPIO38 - pin 4) from Onion Omega. The issue I described is observed when generating a reset pulse on 'HW_RST_N' line (pin 5).

The SW reset works fine, both as a 'normal' reboot or a factory reset. I repeted the test after performing a factory reset and the unit got bricked too when the reset pulse was generated on HW_RST_N line.

Best regards,
Matias

Hi all, I'm experiencing an issue with Hardware Reset on my Onion Omega2 Pro after updating to OpenWrt v23.05.3 based image.

With v0.3.4 (and earlier) images, I sent a reset pulse on CPU_RST line (pin 27 from J2 header) and the device was reset. However, after installing the latest image (onion_omega2p-23.05.3-20250709.bin), the behavior has changed. After sending the same reset pulse (500 ms width), the device gets bricked and becomes unresponsive. The only way to recover it is through a power-cycle.

I wonder if anybody else has observed the same issue and if there is any workaround for it.

Thanks!
Matias

Hi @Lazar-Demin & @crispyoz, I was able to find the root cause for this issue. I've created a pull request in OnionIoT/source github repository with the fix.

@crispyoz thanks for the update. You're correct. The make command does not return an error. However, after it finishes running openwrt-ramips-mt76x8-omega2p-squashfs-sysupgrade.bin is generated but not openwrt-ramips-mt76x8-omega2pro-squashfs-sysupgrade.bin.
When looking into the make command output, the messages shown below are the only reference to the Omega2Pro image.

WARNING: Image file /home/user/onion/source/build_dir/target-mipsel_24kc_musl/linux-ramips_mt76x8/tmp/openwrt-ramips-mt76x8-omega2pro-squashfs-sysupgrade.bin is too big
cp /home/user/onion/source/build_dir/target-mipsel_24kc_musl/linux-ramips_mt76x8/tmp/openwrt-ramips-mt76x8-omega2pro-squashfs-sysupgrade.bin /home/user/onion/source/bin/targets/ramips/mt76x8/openwrt-ramips-mt76x8-omega2pro-squashfs-sysupgrade.bin
cp: cannot stat '/home/user/onion/source/build_dir/target-mipsel_24kc_musl/linux-ramips_mt76x8/tmp/openwrt-ramips-mt76x8-omega2pro-squashfs-sysupgrade.bin': No such file or directory

Please let me know if you have any new finding.

Thanks in advance,
Matias