I have just received a SF32LB52-DevKit-LCD-V1.2.1 with the SF32LB32-MOD-1 (N16R8) for evaluation.
First of all I am wondering if there is a version of the “SF32LB52-MOD-1 Module Datasheet” in english, it seems to be missing from this page.
I am not planning on using the SiFli SDK/build system but will rather be compiling and linking using my own linker script and then flashing directly with sftool. After some trial and error I managed to flash a working blinky program. Since I am not building using the SDK I am a little worried about wiping the flash memory and not being able to recover the original firmware. I have dumped the first 131072 bytes (0x12000000 to 0x12020000) to be safe but I wonder about the rest. I found the ptab.yaml definition here, but it seems like the NOR flash is incorrectly defined:
memory:
- mpi: mpi2
type: nor
size: 8388608 # 8MB
Shouldn’t the nor flash be 16MB for this model?
Here are the partitions I found defined in the partition table:
- name: hcpu_flash_code
type: app
subtype: factory
region: mpi2
offset: 0x20000
size: 7MB
core: HCPU
# DFU application (XIP 执行)
- name: dfu_flash_code
type: app
subtype: dfu
region: mpi2
offset: 0x720000
size: 384KB
core: HCPU
# DFU download region
- name: dfu_download_region
type: data
subtype: raw
region: mpi2
offset: 0x780000
size: 1152KB
# Filesystem region
- name: fs_region
type: data
subtype: filesystem
region: mpi2
offset: 0x8A0000
size: 4MB
# KVDB for DFU
- name: dfu
type: data
subtype: flashdb_kv
region: mpi2
offset: 0xCA0000
size: 16KB
# KVDB for BLE
- name: ble
type: data
subtype: flashdb_kv
region: mpi2
offset: 0xCA4000
size: 16KB
# PSRAM data region (on SiP mpi1)
- name: psram_data
type: data
subtype: ram
region: mpi1
offset: 0
size: 8MB
Can you verify that the rest of the partition table is correct so that I can know what it is I am backing up?
Is the partition table documented anywhere apart from in the SDK source code?
Which parts of the partition table should I not touch even if I am not using the SDK? I imagine that the ble partition might be used by the small core?
If I decide to write my own boot loader is it ok to wipe everything? (apart from possibly the ble partition)
Is it documented in detail somewhere what the boot loader does? I’m especially interested if there are some hardware quirks it accounts for or if I should be ok by just reading the SF32LB52 docs. But I also want to know which parts of the bring-up have already been done by the first boot loader and which need to be performed by the second.
One unrelated concern:
I don’t see any SWD or JTAG pins on this board, is there some intended way to perform run-time debugging apart from printing serial data to the UART port?
If someone from SiFli reads this: A totally off-topic question since you sell via TaoBao, do you know how selling via TaoBao to Sweden/Europe works? I have had a hard time figuring that out. I bought this dev kit from some store on AliExpress.
Best regards,
Oscar
EDIT: Wouldn’t it make more sense to put the filesystem partition next to the application partition? This way the user could choose to grow the application size and give up some filesystem storage if their application doesn’t need all 4MB, or vice-versa. Maybe there is some reason that wouldn’t be a good idea though
you’re right, nor flash size is 16MB, the size field in this part is not used actually
memory:
- mpi: mpi2
type: nor
size: 8388608 # 8MB
all partitons defined in ptab.yaml are not used by bootrom (i.e. 1st bootloader), they’re all related to application. BLE partitionn is not used by small core, it’s used by ble host code running on big core if developing based on our SDK.
if you write your own bootloader (called 2nd bootloadre), only need to keep the first 16KB because it’s the flash table used by bootrom, or replaced with your own ftab.bin like what Zephyr does. Below is the content of flash table for N16R8 module used by hello_world. ftab starts from address 0x12000000. Bootrom reads this table and know that 2nd bootloader code locates in 0x12010000, need to be copied to 0x20020000(XIP base) and run there. main stands for main application, it’s loaded by our 2nd bootloader.
What bootrom(1st bootloader) and 2nd bootloader do is documented here
There’s no SWD pin on the board by default, but UART could still be used for debugging. Please refer to doc for Windows.
For Linux and macOS you can use our VSCode plugin SiFli-SDK-CodeKit. It has contained probe-rs and can be usd to debug SF32LB52 via uart, Related Chinese debugging doc
Regarding the structure of ftab.bin(flash table, C struct type is struct sec_configuration defined in dfu.h), you can read this code to get a rough picture though some information is outdated. The correct index definition used by SF32LB52 is as below, 2nd bootloader is 3
