Skip to main content
Eric1
Eric1
Associate
May 29, 2020
Solved

Odd response when sending FUS (0.5.3) command

  • May 29, 2020
  • 3 replies
  • 1046 views

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.

This topic has been closed for replies.
Best answer by Eric1

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.

3 replies

Remi QUINTIN
Remi QUINTIN
Technical Moderator
May 29, 2020

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?

Eric1
Eric1Author
Associate
May 29, 2020

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
Eric1AuthorAnswer
Associate
May 30, 2020

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
Remi QUINTIN
Technical Moderator
June 2, 2020

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.

Terms & ConditionsAccessibility statement