[BUG] stub patching using json config doesn't work

Pre-submission checklist

• I have read the SiFli documentation and the issue is not addressed there.
• I have updated to the latest version of sftool and confirmed the issue still exists.
• I have searched the issue tracker for a similar issue and not found a duplicate.

Bug Category

Flash Operations - Problems with write_flash, read_flash, erase operations

sftool Version

sftool 0.2.5

Operating System

Windows 11

Target SiFli Chip Model

SF32LB52

Command Executed

./sftool.exe --stub-config .\custom_stub.json --port COM3 read_flash ./out.bin@0x12000000:0x40000

Bug Description

Essentially, I can't get the json stub patching functionality to work properly. There is first a minor bug in the parsing, where I can't use hex numbers to parse the various NOR config fields, but then also the specified configuration doesn't result in successful flashing. You can see attached the custom json stub config that I made, that is supposed to be strictly equivalent to the stub file I patched using the BurnDriverEx utility (screenshot attached), yet reading and writing the flash works well with the patched stub, and not with the json configuration (specifically it reads all zeroes, and doesn't write anything).

custom_stub.json

What is the expected behavior?

I would have expected the json patching to be exactly equivalent to patching using the utility software.

What is the actual behavior?

Using JSON configuration, the behaviour is very weird. I can say that some of the patching works, for example the manufacturer id, device id and density id work correctly (even though I can't configure them as hex values) because if I don't set them right the chip fails to communicate with the flash in the first place. The driver index seems to be doing something, but most of the time it simply changes the value the read_flash gets stuck at. My flash is supposed to be of type 1, but the only type that is somewhat able to read data is type 3, and only the first hundred bytes or so(and only with an offset of 1 byte compared to the actual RAM content...)

Steps to reproduce

Try to do sftool read_flash on a flash chip using a custom stub json config. I don't know if this issue affects only my specific FLASH model or type, I don't have access to any other flash chip to test.

Bug Severity

Medium - Minor functionality affected, workaround available

Hardware Setup

I use a custom PCB designed by me. It uses a SF32LB525UC6, and the flash chip is a W25Q16RVXHJQ from Winbond. I connect to the SF32 using a serial to usb adapter. The FLASH is connected to the SF32 on MPI2, and works as expected (I am able to program and run programs as normal, so a faulty PCB layout shouldn't be the main problem here)

The WINBOND flash chip should fall under NOR type 1.

Installation/Build Details (for installation/build issues)

I downloaded the last sftool release and patched the patch files found in the repo under sftool-lib.

Environment Details

Error Messages and Complete Output

S C:\Users\Elie\Downloads\sftool-0.2.5-i686-pc-windows-msvc> ./sftool.exe --stub-config .\custom_stub.json --port COM3 read_flash ./out.bin@0x12000000:0x40000
[0x00]   Connected success!                                                                                                    [0x01]   Download stub success!                                                                                                [0x02] Read complete ===================================================================================== 64.60 KiB/s 100.000%
PS C:\Users\Elie\Downloads\sftool-0.2.5-i686-pc-windows-msvc>

(results in an empty bin file, except for two bytes that I have set previously using write_flash and the same configuration. This is very weird because these bytes persist across chip resets and sftool rebuilds. I'm guessing maybe the tool wrote at an incorrect location, or some form of caching is involved ? Either way, very weird)

Verbose/Debug Output (if available)

Attempted Solutions

No response

Working Configuration (if any)

The patched bin file works perfectly, as seen in the previous screenshot. The flash content is exactly identical to what I can see in the OZONE debugger's memory view for example. Programs flashed also work as expected.

Additional Information

No response

Start by reproducing the shown read_flash command with custom_stub.json and inspect the stub-config parsing and patch files under sftool-lib. Compare JSON patching with the working patched bin on the SF32LB525UC6 and W25Q16RVXHJQ setup. Done means hexadecimal NOR values parse correctly and JSON-configured read/write behavior matches the utility-patched stub.