FAQ
TL;DR: OpenBK’s 64-bit Flags update was checked on 2 targets first, and testers then expanded it across Realtek, XR809, and TR6260. One maintainer called per-device testing "finally meaningful" because Windows checks cannot validate SDK functions like strtoull() on real MCUs. This FAQ helps OpenBK contributors verify PR 1548 safely and separate true 64-bit parsing results from older flag-13 bugs. [#21457658]
Why it matters: A flags parser that works on Windows but fails on one SDK can silently break settings, web UI behavior, or reboot persistence on real hardware.
| Option |
What it checks well |
Main limitation |
strtoull(args, NULL, 10) on device |
Real 64-bit decimal parsing on ESP, BL, LN, Beken SDKs |
Must be validated per platform |
sscanf("%lld", ...) on device |
Alternate 64-bit read path for comparison |
C library behavior can vary by SDK |
| Windows simulator tests |
Fast regression checks on every commit |
Cannot prove SDK-specific libc behavior |
Key insight: The thread’s main conclusion is that the 64-bit Flags PR itself looked good on tested 32-bit OpenBK platforms; the notable failures pointed back to pre-existing platform-specific issues, especially the older flag 13 behavior and SDK quirks.
Quick Facts
- The original verification started on the simulator and BK7238, then expanded to ESP-, BL-, LN-, and Realtek-based targets to validate
strtoull() outside Windows. [#21457366]
- The on-device test runner uses
StartTest 100, where 100 ms is the interval between printed test steps and result checks. [#21457592]
- Testers reported RTL8195A Hard Fault logs after setting all flags, yet the device rebooted with all but 1 flag set, which strongly suggested a separate platform/UI issue rather than failed 64-bit parsing. [#21457513]
- Windows simulator self-tests already run on each commit, while the newer per-platform tests must be started manually on physical hardware. [#21458712]
- A maintainer listed prior cross-platform faults involving 32-bit vs 64-bit
time_t, missing realloc on BL602, and unusual sprintf behavior, showing why device-level checks matter. [#21457368]
How can I verify the new 64-bit Flags command in OpenBK7231T_App on platforms other than BK7238 and the simulator?
Use a real-device check focused on the parser, not every board family. 1. Flash the PR build to one device per SDK family, such as ESP, BL, LN, or Realtek. 2. Run
flags 18446744073709551615. 3. Confirm the value displays correctly, saves, reboots cleanly, and does not trigger SDK-specific faults. The thread says all current OpenBK targets are 32-bit, so broad device duplication is unnecessary; the key question is whether
strtoull() works on each main SDK outside Beken.
[#21457366]
Why were OBK flags originally stored as two integers instead of a single uint64_t?
They were likely split because the project started with only 32 flags, then grew later. One maintainer said the code began with a single 32-bit integer and another 32 bits were added afterward, which also exposed a long-standing bug in setting or reading flags. That history explains the two-part storage better than a deliberate preference for
uint64_t. The thread does not give a stricter architectural reason than that evolution path.
[#21457325]
What problems can happen if OpenBK uses long for flags on platforms where long might be 8 bytes?
It can break config layout and make stored flag data platform-dependent. That risk appeared immediately in review, and the fix was to switch the code to
uint32-based parts instead of relying on
long. This matters because OpenBK is 32-bit today, but future ports or unusual compilers could size
long differently. In short, fixed-width integers keep 64-bit flags stable across builds, while
long can shift structure size and storage rules.
[#21456907]
What is strtoull() in C, and why is it being used to parse 64-bit flag values in OpenBK?
"strtoull() is a C library function that converts a text string into an unsigned long long integer, using a chosen base and returning a 64-bit-capable value on supported SDKs." OpenBK uses it because the command input arrives as text, and PR 1548 needs to read values up to
18446744073709551615 in base 10. The tested code path shown in the thread is
u.newValue = (uint64_t)strtoull(args, NULL, 10);, which directly matches the 64-bit Flags goal.
[#21457366]
How does strtoull(args, NULL, 10) compare with sscanf("%lld", ...) for reading 64-bit flags across ESP, BL, LN, and Beken SDKs?
strtoull(args, NULL, 10) was treated as the main path to test, while
sscanf("%lld", ...) was considered a useful comparison target. The thread’s maintainers wanted both covered by the new per-platform tests because those functions come from each SDK’s own C library, not from OpenBK. That means a Windows pass does not prove they behave the same on ESP, BL, LN, or Beken. The practical conclusion was to add on-device tests for both parsing routes.
[#21457621]
What is a Hard Fault on RTL8195A or RTL8720D, and how do you troubleshoot it when changing OBK flags?
A Hard Fault is a platform crash reported by the MCU runtime, often with register dumps and a halted or rebooting system. In this thread, RTL8195A printed a Hard Fault log after setting all flags, but later testing showed a similar crash with general release 1.18.47 and only flag 13 set. To troubleshoot, reproduce with a release build, test a single flag such as 13, and compare behavior before and after PR 1548. If the older build crashes too, the fault is not caused by the 64-bit Flags change.
[#21457513]
How do I run the new per-platform self-tests on a physical OpenBK device using ENABLE_TEST_COMMANDS, startDriver Test, and StartTest 100?
Build a test-enabled firmware and run the device test driver. 1. Enable
ENABLE_TEST_COMMANDS in
obk_config.h, then add test commands in
cmd_test.c and register them. 2. Add them to
drv_test.c and compile the firmware. 3. Flash the device and run
backlog startDriver Test; StartTest 100;, where
100 means a 100 ms interval between steps. The runner prints each command, waits, executes it, checks the result, and continues.
[#21457592]
What is the difference between the Windows simulator self-tests and the new per-platform device tests in OpenBK?
Windows simulator tests catch logic regressions on every commit, while per-platform tests catch SDK and libc differences on real hardware. The Windows set runs in GitHub and validates use cases like channels, PWM, MQTT, or HTTP behavior inside the simulator. The newer device tests run only on flashed hardware and target platform-specific functions such as
sscanf,
sprintf,
realloc, and parsing code. That split matters because a simulator pass cannot prove behavior on BK7231, W600, LN882H, or Realtek libraries.
[#21458365]
Why did flag 13 fail to persist after reboot on RTL8720D, XR809, and TR6260 even though the 64-bit flags PR seemed to work?
Because the thread consistently treated flag 13 as a separate, older bug. Testers said RTL8720D, XR809, and TR6260 accepted the new 64-bit flag value, but flag 13 still cleared after reboot or triggered UI crashes. The PR author explicitly said the RTL8720D flag 13 problem was not related to PR 1548, and later reports on XR809 and TR6260 matched that same pattern. So successful 64-bit parsing and broken flag 13 persistence can happen together.
[#21459741]
Which OpenBK platforms actually need testing for the 64-bit Flags PR if most supported MCUs are currently 32-bit?
You only need representative testing across the main SDK families, not every 32-bit board. The thread says there is no need to test all devices because current OpenBK targets are 32-bit; instead, the important check is whether
strtoull() behaves correctly on ESP, BL, and LN, since Beken was already confirmed. A few cross-family samples therefore give higher value than many same-SDK boards. That keeps validation focused and fast for PR 1548.
[#21457366]
How can per-platform self-tests catch SDK-specific issues like sscanf, sprintf, realloc, time_t size, or IP parsing bugs that Windows tests miss?
They run the suspect code on the actual SDK implementation, then return
CMD_RES_ERROR if the result is wrong. The thread gives a concrete IP example: parse
192.168.0.123, then verify all 4 bytes. That mattered because
%hhu handling had already failed on W600, LN882H, and Realtek, and
realloc was still suspected broken on BL602. Windows tests cannot expose those MCU-specific libc differences, but per-device tests can fail immediately on hardware.
[#21458365]
What is LLP64, and why does long stay 32-bit on 64-bit Windows while other platforms may behave differently?
"LLP64 is a data-model convention that keeps long at 32 bits while pointers and long long use 64 bits, which makes 64-bit Windows behave differently from many Unix-like 64-bit environments." That mattered in the thread because a contributor worked mainly on 64-bit Windows and assumed
long behavior from that world. They then corrected the code to use fixed-width integers after realizing Windows LLP64 does not guarantee portable flag storage elsewhere.
[#21456907]
Why did the OBK web UI show incorrect behavior for a flags value of 0, and how was that display bug fixed?
The web UI had a display issue for the exact value
0, separate from the 64-bit parser itself. After more testing, the PR author said they fixed the zero-value display and credited another tester for identifying it. They also stated the updated behavior was fine from their side after that correction. The thread does not publish the exact code change, but it clearly separates the UI bug from the core 64-bit flag parsing work.
[#21459741]
What is the best way to add a dedicated 64-bit FLAGS self-test in OpenBK so future PRs do not break parsing or storage?
Add a per-platform command test that exercises both parse and persistence paths on real devices. A solid version should set a full 64-bit decimal value, read it back, save, reboot, and compare again; then add negative checks for
0 and a single-bit case like flag 13. The maintainer explicitly said they would add a FLAGS test for 64-bit flags, and that is the right place to verify
strtoull() and
sscanf() behavior outside Windows. This keeps future regressions visible before merge.
[#21459788]
When testing PR 1548 on Realtek, XR809, or TR6260, what results suggest the issue is unrelated to the flags fix and instead tied to the older flag 13 bug?
The clearest sign is this pattern: the new 64-bit value sets correctly, but flag 13 still clears on reboot or crashes the main page exactly as older releases did. That happened on Realtek-family tests, XR809, and TR6260. One tester even reproduced the same fault on general release 1.18.47 using only flag 13, which isolates the failure from PR 1548. If baseline firmware shows the same reboot-persistence or UI crash, blame the older flag 13 issue, not the 64-bit parser.
[#21459843]
Generated by the language model.
), maybe this weekend.
