cancel
Showing results for 
Search instead for 
Did you mean: 

Odd response when sending FUS (0.5.3) command

Eric1
Associate II

I'm using a custom board with a STM32WB50CG part. When I send this:

0x10 0xFC 0x52 0x00 (FUS_GET_STATE) 

or any command for that matter, I always get this back:

0x11 0x0E 0x04 0xFF 0xFE 0x00 0xFE 0x00

I've tried this while running the bootloader code as well as my own code.

Anyone see the error in my command? I've mostly followed AN5185. But there's errors in that app note. For example Section 6.1 says FUS only uses the device information table and system table, yet the bootloader also fills in the async event table. Only after filling in that table do I see the event announcing CPU2 is up and running FUS.

1 ACCEPTED SOLUTION

Accepted Solutions
Eric1
Associate II

Ok. I figured out what my problem was.

The system table points to a buffer the FUS will write responses to, but it reads the command 2 words higher, not in the same address. The documentation says it “overwrites�? the command, but that’s very misleading.

View solution in original post

4 REPLIES 4
Remi QUINTIN
ST Employee

Are you using the CubeProgrammer tool in GUI or CLI mode? what is the version?

What port do you use (USB, UART or SWD) to communicate with the chip?

Can you add a log of the sequence of command you are using?

I’m using a Segger JLink connected using SWD. Also using the Segger IDE mostly. I’ve attached the debugger while the STM32 is in boot loader, directly filled in the command to memory and sent the IPCC toggle. I can see CPU2 overwrite the command with the response. I’ve tried formatting the command multiple ways and always get the same response. Any suggestions?

Eric1
Associate II

Ok. I figured out what my problem was.

The system table points to a buffer the FUS will write responses to, but it reads the command 2 words higher, not in the same address. The documentation says it “overwrites�? the command, but that’s very misleading.

Remi QUINTIN
ST Employee

Indeed the FUS uses the Async event table and that’s only at startup to tell CPU1 that CPU2 is ready to receive commands.

So you are probably receiving the async READY event after the sending of the command because the Ready event remained in the pipe since the startup.

But this message can be ignored, it shall not cause any problem.