Reset button troubleshooting - DFRobot IoT Mini Router | CM4 32 GB eMMC, WiFi, 8 GB RAM

Community Builds, Projects & Packages
#1

Hi everyone,

I'm hoping I can get some help with this issue I'm having using the DFRobot IoT Router Mini Carrier Board, as I'm trying to make a video on it and to showcase it's abilities. As noted in the title, I'm using a CM4 with 32 gb eMMC, 8 GB RAM, and with WiFi.

I first flashed it with the DFRobot OpenWrt image, however, I found it unsatisfactory for a few reasons, but one reason in particular, was because the image provided was a ext format, and not in sqaushfs. Having a reset button, I'm surprised they offered an ext filesystem, as it makes the reset button a moot point.

Anyway, I went ahead and flashed a custom image of OpenWrt using squashfs. After that, I made a minor network change for a different /24 subnet, then attempted a reset by holding the button down for ten seconds, as noted in OpenWrt documentation. After it reboot, I was surprised to see that it still retained its /24 network that I had changed it too. As you'd figure, I expected it to change to the factory default network, but alas it did not.

I started doing some research and I dug into the script /etc/rc.button/reset to see what it did. It seemed to make sense, and so I did more testing.

In the script, I noticed this part that was responsible for the reset.

case "$ACTION" in
...
released)
        if [ "$SEEN" -lt 1 ]
        then
                echo "REBOOT" > /dev/console
                sync
                reboot
        elif [ "$SEEN" -ge 5 -a -n "$OVERLAY" ]
        then
                echo "FACTORY RESET" > /dev/console
                jffs2reset -y && reboot &
        fi
;;
esac

So to me, it looks like I need to hold down the reset button for at least 5 seconds (along with checking the filesystem is overlay) and then it initiates the reset.

To me, it looks like it's initiating a reboot, and not a reset. However, this is where my hit a roadblock. I am not sure how I can check within a serial console, if a reset (or reboot) is actually happening. In the serial console, I don't see any output after I release the button. I'm not sure if this is expected, but just thinking out loud.

I will say I noticed as soon as I pushed down the reset button, the networking stopped (my host machine lost it's IP address assigned by OpenWrt).

I also tried to create random text files on the filesystem, and those persisted after pressing and holding down the reset button.

Lastly, I verified the command in the reset button script to see if it did the hard reset I expected, by copying it and pasting it in my console, and sure enough it worked.

jffs2reset -y && reboot &

This was at least to me, a verification that indeed it was initiating the reset, or the script was not being called by the reset but press, and hold down for 5 seconds.

Has anyone else used the DFRobot CM4 carrier board and experienced this? Or does anyone have additional troubleshooting steps I can do to at least see what script, or commands, are being called when I press the reset button? If so, then at least from here I can maybe see whats going on, and try to fix or get the reset button working.

From my research, I figured this would work be default, standard for a squashfs build on hardware that has a reset button, but maybe I'm wrong.

Here is a link to the DFRobot CM4 Carrier board wiki, for reference.

Thanks in advance,
Orest

#2

Perhaps this reset button is hooked to the CPUs reset line, and acts as a hardware reset, instead if a GPIO that can be captured by software?

#3

Thanks to taking the time to reply!

That could be possible, I didn't even think of this as an option. If you click on the link here and check out the diagram(s), is it possible to see if it is a CPU reset line? It almost feels like it is given the first picture you see.

With regards to your second statement, if this is a CPU reset line, then there would be no way to capture the action being done, via software?

Otherwise, I'll reach out to the DFRobot as well to get some more detail around this.

#4

I could not find any conclusive documentation, but the processor on the Raspberry Pi Compute Module 4 has a RUN_PG pin, independent from other GPIOs; this is a hardware reset, that cannot by captured by any software.

If your module has that pin wired to the reset button, then you will not be able to do anything useful with it.

#5

Thanks for looking into it! I did message DFRobot to see if I can verify the information you are talking about.

Also thanks for sharing that. My electronics knowledge, or let along knowledge of PCBs and pins are par at best. Thats interesting it has its own RUN_PG separate from the other GPIOs. Given thats directly embedded in the hardware, I can see why there is no way this would be possible to capture it in the software.

More likely than not, I feel that this is the case, as I see absolutely nothing in the console, indicating a software "hard reset" is occurring. For purposes of documentation and sharing, once (if) I get a response from DFRobot, I'll share it here.

Other than that, I have a question. Is there anything useful about this hardware reset? If you happen to know the general purpose of a hardware reset, I'd be curious to hear about it.

Thanks!

#6

A soft reset executes a piece of code, that performs some tasks, then reboots the device. If that piece of code fails, the device may or may not reboot, and the user has to power-cycle the device.

A hard reset acts directly on the CPU, there is no opportunity to execute any shutdown code, but the device will always reboot.

I guess each one has its place, and sometimes one is more convenient than the other.

#7

I would wonder if the ability to either pull the microSD card from the Pi (or hook an eMMC equipped version up to a PC as a mass storage device) had anything to do with the design choice. A factory reset button has less value on a device where you can (relatively) easily access the file system on another device and either fix the misconfiguration or reflash the entire image.

1 Like
#8

Thanks for that explanation, that makes sense to me. The soft reset is what most expect, I believe, with a router, when they push a reset button.

It sounds like a hard reset is there for when a soft reset fails. Being directly hard lined to the CPU, it can reset the CPU directly when it's potentially in "failing" state. In this sense, since it bypasses software, the hard reset won't be stopped by a bad software state.

@krazeh

That is a point worth thinking about too. If it's ever in a bad running state, mounting the file system on another computer should allow you to fix and changes that put the device in an "virtually" inaccessible state.

I appreciate the feedback, good talking points too. I doubt DFRobot will get back to me soon, so this information is probably what I'll settle on, at least for the time being.

Thanks to you both!

1 Like