Please add instruction to flash bootloader first time to Sengled G4 #148
|
I acquired another Sengled G4 unit. Thanks to your excellent support to make this model run smoothly with those alternative firmware 👍 When started the first unit, since the support was not in place, I had to run custom steps. With the second unit, I like to try your scripts as is. Flashing RTL8196 firmware went smoothly, thanks a lot for your efforts make it so easy now. I encountered some issues when flashing radio firmware, and I would like to report back here and it would great you can update documentation for this.
One enhancement request ( low priority, feel free to update after v4.0.0 release): With z3 router firmware in place, when I tried to flash new firmware, ( I didn't use the manual step of sending 1 to blmode_pulse) It takes a long to cycle through all different ways to enter bootloader mode, and finally find one that can flash firmware. It would be great that the script can based upon board type to send an optimized way to enter bootloader mode (for Sengled G4, it is send 1 to |
Replies: 4 comments 17 replies
|
One issue just found with the bootloader is that i no longer able to enter bootloader mode with blmode_pulse |
|
Thank you for both reports — and congratulations on the second unit. Your two messages turn out to be the same fact, so let me take the second one first, because it is the one that explains everything else. Why
|
|
@jnilo1 i already flashed the bootloader to the second unit when testing it. Based upon PCB trace, it is PB15 on erf32. Thanks for working on the fix! |
Not until just now — thank you for asking before closingHonest answer: no. The two bootloader fixes and the fast path landed, and the script bugs you found are fixed, but the thing you actually opened #148 for — the instructions — was still missing. You asked the right question. It is written now, so please do close once you have looked it over.
# On the gateway. Stop whatever is holding the bridge port first (it accepts a
# single client), then park the bridge where the bootloader lives.
SYSFS=/sys/module/rtl8196e_uart_bridge/parameters
echo 115200 > $SYSFS/baud
echo 0 > $SYSFS/flow_control
echo 1 > $SYSFS/blmode_pulse # hardware entry — the stock bootloader samples this pin
# On the host, from 23-Bootloader-UART-Xmodem/firmware/
sz -X -o --tcp-client 192.168.1.88:8888 bootloader-uart-xmodem-2.4.3-sengled-e39-g8c.gblThe section states plainly why the script cannot do this one step: Two things I made explicit for whoever follows you, because both are easy to get wrong and neither is visible from the outside. The bridge settings are not decoration: the bootloader's Xmodem path runs at 115200 with no flow control, and since the G4 wires no RTS/CTS the bridge defaults to This is a one-time step by construction: our bootloader has a menu, so everything after it — applications, and the bootloader's own future updates — is Committed as |
|
@jnilo1 Thanks for the write up! It looks great. One minor request to cover a corner case: If G4 accidentally flashed with Lidl bootloader, "blmode_pulse" doesn't work, and the script won't be able to flash new bootloader as it expects "blmode_pulse" can reliably enter bootloader mode. Can we add an option to bypass "blmode_pin" detection and use standard bootloader detection method? It is not an urgent enhancement, we can do it after v4.0.0 release. Thanks again for implementing "blmode_pulse" and short path for G4! |
Good corner to raise — the bypass is already there, and it is automaticThe pulse is best-effort, not a precondition. Nothing downstream depends on it having worked: the pulse fires, and then the probe decides what happens next. Here is the whole of it ( BLMODE_GPIO=$(ssh_gw "cat ${BRIDGE_SYSFS}/blmode_gpio 2>/dev/null" || true)
if [ -n "$BLMODE_GPIO" ] && [ "$BLMODE_GPIO" != "-1" ]; then
echo "Hardware bootloader entry: pulsing blmode (GPIO ${BLMODE_GPIO})..."
set_bridge_baud 115200
set_bridge_flow_control 0
ssh_gw "echo 1 > ${BRIDGE_SYSFS}/blmode_pulse" || \
echo " blmode pulse rejected — falling back to the in-band path." >&2
wait_for_port "$GW_IP" "$GW_PORT"
fi
echo "Pre-check: is chip already in Gecko Bootloader?"
if BTL_RUNNING_VERSION=$(probe_bootloader); then
PROBE="bootloader:115200"
else
BTL_RUNNING_VERSION=""
set_bridge_baud "$CURRENT_BAUD"
...
PROBE="ezsp:${CURRENT_BAUD},cpc:${CURRENT_BAUD},spinel:${CURRENT_BAUD},bootloader:${CURRENT_BAUD}"
echo " Chip is running an app — probing at ${CURRENT_BAUD} baud."
fiOn a G4 carrying a bootloader with no GPIO activation compiled in, the pin is never read, the radio simply reboots into its application, I did not want to assert that from reading the code, so I reproduced your scenario on the benchYou are right that this needed checking rather than my say-so, and until today no board here could produce a failed pulse: the Lidl keeps So I built that state on a Lidl. That is the bypass, working, with no flag and no user action. Nothing was written to the radio to get this — the fall-through is decided before any flash begins. The pre-flight guard covers the same corner deliberately: the running bootloader version is only readable while the chip is in the bootloader, so when the pulse does not land and the application is running, it falls back to One real finding out of your questionStep 1 above is a small lie of the driver's: it prints Two notes on the literal scenarioFlashing a G4 with the Lidl bootloader through the script takes And if you ever want the pulse skipped explicitly today, without a new flag: So: do you still want the flag?I would rather not add a |
Done — the log no longer claims what it cannot seeShipped, I fixed the opening line too, not just the closing one I promised you: Verified on the bench in the misleading case itself — the same rig as before, a pulse on a pad the radio cannot hear — so the lines above are what the driver really prints when the pin goes nowhere, not what I expect it to print. Both kernel overlays (6.18 and 7.1), and I refreshed the prebuilt images for both boards: the driver is identical across them, and shipping a G4 image still carrying v1.5 would miss the board this exists for. Your pre-flight guard had a hole, and the same test found itWorth telling you since the guard was your idea. It compared the image and running bootloader versions only when it had both, and fell through in silence when it did not — so a file whose version cannot be read reached the flasher unchallenged. An application The two figures fail in opposite directions, so they are handled apart now. An unreadable image version refuses ( Both ride v4.0.0. Thanks again — the flag question was worth asking even though the answer was "no flag needed": it is what got the fall-through measured instead of assumed, and it turned up the hole above on the way. |
|
@jnilo1 Thanks for the enhancement! As long as the script will fallback to probe mode if Close the discussion |
|
@jnilo1 Thanks a lot providing new bootloader! There is good news and bad news.
a) after reboot, it stays at bootloader mode ( which matches statement in log message
In summary, |
|
@jnilo1 Thanks for debugging this issue. Bootloader 2.4.3 you provided works as expected. I was able to flash it into G4. And Do you think |
Confirmed on hardware — and your pre-flight check is in
Your question: yes, and it belongs before the flash, not afterYou are right, and it exposes the weakness in what I had built. My check ran after the upload — it told the truth, but only once the application had already been erased. Yours prevents the damage instead of reporting it. So Before flashing, it parses the version out of the
The version is per board now, and the Lidl does not move
For the record, since the numbering looks like it claims something it does not: And the fast path from #123Now that the pin is proven, That closes the debt from #123. When you will get itAll of this is committed, but it ships in v4.0.0, which is still gated on the issue #99 field soak — the UART interrupt storm. That fix is in and behaving, but "behaving" for a bug that was twice declared solved and twice came back means weeks of clean uptime on real gateways, not a green bench. I am not cutting a release before that clock runs out, and this work is not urgent enough to jump the queue: you already have the bootloader that matters, and it is the same binary. If you want the host-side pieces before then — the pre-flight guard and the |
|
@jnilo1 Thanks for implementing the enhancement for |
Here it is — drop-in replacement, nothing else has to change
What it now does on your G4The Two more things ride along, both from the debugging above. The pre-flight guard parses the version out of the One coupling, only if you rebuild the bootloaderThe pre-flight guard reads the version straight out of the That is the whole host side of #148. PB15, the bootloader, and now the flasher are all confirmed on your hardware; the complete set rides v4.0.0 behind the #99 soak, and it is the same binary and script you already have in hand. |
|
@jnilo1 Thanks for sharing the updated script! I encountered some issue using it |
Done — the log no longer claims what it cannot see
Shipped,
rtl8196e-uart-bridgev1.5 → v1.6:I fixed the opening line too, not just the closing one I promised you:
entering EFR32 bootloaderasserted the same unknowable outcome. Both now state what the driver did; what the chip is actually running is the probe's job to establish, and the code says why in place, so nobody re-adds the claim later.Verified on the bench in the misleading case itself — the same rig as before, a pulse on a pad the radio cannot hear — so the lines above are what the driver re…