Broken FUS version

ACham.3 · ‎2021-05-27

Hi,

I'm using a custom board with STM32WB55 and faced with an issue related to FUS up and running. Initially, I was able successfully to upgrade FUS up to 1.1.2.0 via swd interface. Then I have updated the user key via USART embedded bootloader. Started from this point everything works fine until I performed the power cycle. After that, FUS stops working. When I'm trying to read FUS info I get "0x20030030 : EFF742A0"

Before getting FUS info I always send STM32_Programmer_CLI -c port=swd -fusgetstate command several times and it replies "FUS_STATE_IDLE" every time.

Read back DIT table shows results as follow:

0x20030024 : 88842F65 04FF4224 E344FADB EFF742A0

0x20030034 : 3D4C3EF7 13CFC074 68D055F6 6FFE65C3

0x20030044 : F674573E 5FB11850 C24ADA6B ACBB243B

0x20030054 : 4206EEED

Also, I'm not able to upgrade FUS version up to v1.2.0.

As I understand from the doc CM0+ core responsible for FUS running. Is that possible that this core not running anymore or stuck somewhere? If not, how to make FUS working?

Thanks.

Remi QUINTIN · ‎2021-05-31

When using the SWD interface, the FUS version is not located at 0x20030030.

As mentioned in the AN5185, The first word in SRAM2a pointed by IPCCDBA Option Bytes is the "Device info table" address. This table

(described in Table 7. Device information table) contains the FUS version at offset 0xC which is encoded on four bytes.

Please first check that point.

Then have a look at all the option bytes and provide them.

FUS v1.2.0 is available in the WB FW package v1.11. What type of error do you get?

What is the version of the CubeProgrammer used to upgrade the FUS?

Indeed, the FUS is run on the M0+ core. When booting with the appropriate option bytes that enables the connection via the SWD interface, the CM0+ should properly boot and the FUS operator running on the M4 core at 0x08000000 send commands (such as FUS_GET_STATE) to the FUS.

ACham.3 · ‎2021-06-01

I have IPCCDBA = 0x0000, and DIT table seems placed in a correct place:

r ap 0 @0x20030000 0x00000004 bytes Data 0x20030024

I'm using CubeProgrammer v2.7.0: in according to AN5185:

"When using the SWD interface with the STM32CubeProgrammer (STM32CubeProg) older than V2.7.0, the address of the device information table is located at 0x20030890. For STM32CubeProgrammer V2.7.0 and higher, the device information table is located at 0x20030024."

So, FUS version should be located at 0x2003030. Or I miss something?

Reading DIT table I get result as follow:

This is option bytes I have:

Read Out Protection:

RDP : 0xAA (Level 0, no protection)

BOR Level:

BOR_LEV : 0x0 (BOR Level 0 reset level threshold is around 1.7 V)

User Configuration:

nBOOT0 : 0x1 (nBOOT0=1 Boot from main Flash)

nBOOT1 : 0x1 (Boot from code area if BOOT0=0 otherwise system Flash)

nSWBOOT0 : 0x0 (BOOT0 taken from the option bit nBOOT0)

SRAM2RST : 0x1 (SRAM2 is not erased when a system reset occurs)

SRAM2PE : 0x1 (SRAM2 parity check disable)

nRST_STOP : 0x1 (No reset generated when entering the Stop mode)

nRST_STDBY : 0x1 (No reset generated when entering the Standby mode)

nRSTSHDW : 0x1 (No reset generated when entering the Shutdown mode)

WWDGSW : 0x1 (Software window watchdog)

IWGDSTDBY : 0x1 (Independent watchdog counter running in Standby mode)

IWDGSTOP : 0x1 (Independent watchdog counter running in Stop mode)

IWDGSW : 0x1 (Software independent watchdog)

IPCCDBA : 0x0 (0x0)

Security Configuration Option bytes - 1:

ESE : 0x1 (Security enabled)

PCROP Protection:

PCROP1A_STRT : 0x1FF (0x80FF800)

PCROP1A_END : 0x0 (0x8000800)

PCROP_RDP : 0x0 (PCROP zone is kept when RDP is decreased)

PCROP1B_STRT : 0x1FF (0x80FF800)

PCROP1B_END : 0x0 (0x8000800)

Write Protection:

WRP1A_STRT : 0xFF (0x80FF000)

WRP1A_END : 0x0 (0x8000000)

WRP1B_STRT : 0xFF (0x80FF000)

WRP1B_END : 0x0 (0x8000000)

OPTION BYTES BANK: 1

Security Configuration Option bytes - 2:

SFSA : 0xF4 (0x80F4000)

FSD : 0x0 (System and Flash secure)

DDS : 0x1 (CPU2 debug access disabled)

C2OPT : 0x1 (SBRV will address Flash)

NBRSD : 0x0 (SRAM2b is secure)

SNBRSA : 0x0 (0x20038000)

BRSD : 0x1 (SRAM2a is non-secure)

SBRSA : 0x0 (0x20030000)

SBRV : 0x3D000 (0x20000000)

Remi QUINTIN · ‎2021-06-01

Indeed, you're right. the DIT shall be located at 0x20030024. In that case the FUS version is weird!!

FUS v1.2.0 is available in the WB FW package v1.11. Did you try to update this one?

The option bytes look OK and consistent.

In last resort, you could try to write 0x00008000 at address 0x5800040C. This C2BOOT bit enables the boot of CP2 and reset the WB device to its manufactory state.

ACham.3 · ‎2021-06-02

I was trying to write 0x00008000 at address 0x5800040C using the command:

STM32_Programmer_CLI.exe -c port=swd -w32 0x5800040C 0x00008000

but result the same

During the first try of FUS upgrade up to v1.2.0 I got en error "FUS_STATE_ERR_UNKNOWN" after the second try it shows "Firmware Upgrade Success" but FUS version still broken.

Start address is correct,

Remi QUINTIN · ‎2021-06-03

When you say "FUS is still" broken, do you mean the FUS version still looks weird despite the "Firmware Upgrade Success" message?

I will discuss with the security team about those strange numbers reported for the FUS version.

Did you try to activate the anti-rollback button? I would not recommend it for now.

Anyhow can you try to upload the M0+ FW in the Flash memory?

ACham.3 · ‎2021-06-03

Yes, FUS version still looks weird.

No, I didn't try anti-rollback functionality

Do you mean put stm32wb5x_FUS_fw.bin starting from address 0x080EC000? If yes, it didn't help.

Remi QUINTIN · ‎2021-06-08

No I was thinking about loading the M0+ FW