Updating ISM 43362 WiFi module firmware on B-L475E-IOT01A board - SOS!

[TDJ]

Today I attempted to update ISM43362 WiFi module firmware on my new B-L475E-IOT01A board.

I downloaded this firmware update utility, dedicated for my board from ST site and followed the steps in the README file. The process uses Cube Programmer CLI and has three stages:

• Programming the bootloader passthrough
• Erasing the Inventek WiFi firmware
• Programming the Inventek WiFi firmware

The first stage completed OK, but the second and the third stages failed.

ISM 43362 WiFi module is no longer recognized.

What is alarming is that at the second stage wrong Cortex core and ChipID is detected. See the attached scrsht. It seems like ST published the wrong bootloader, meant to be used for STM32F2xx MCU, instead STM32L4xx.

Please help, I am screwed :\

[Guillaume K · Accepted solution]

Hello

I see same problem as you.

I tested with latest STM32CubeProgrammer version 2.11 like you.

Maybe there's a new way to manage UART connections in newer versions of STM32CubeProgrammer that changed delays and timeouts for UART connections.

I found a workaround: once the Inventek firmware is erased (and generates timeout error) I unplugged and replugged the board to remove power. Then I run the last STM32_Programmer_CLI command independently on CMD prompt.

If you already run the script, the STM32 pass-through firmware is already flashed and the Inventek firmware is already erased (even if there is a timeout error at the end).

Try to unplug the B-L475E-IOT01 from USB, re-connect it to USB, then run only the last command in the update_Wifi.bat batch file (to update Inventek firmware):

(in a DOS CMD prompt, in the directory where ISM43362_M3G_L44_SPI_C3.5.2.7.STM.bin is located)

"C:\Program Files\STMicroelectronics\STM32Cube\STM32CubeProgrammer\bin\STM32_Programmer_CLI.exe" -c port=COM5 br=115200 p=even db=8 sb=1 fc=OFF -d ./ISM43362_M3G_L44_SPI_C3.5.2.7.STM.bin 0x08000000 -v

note: in the example I use port=COM5 as in your screenshot.

it takes a long time to write and verify, but in the end it works in my case.

it seems the identification of STM32F2xx instead of STM32L4 doesn't cause problem.

[TDJ]

@Guillaume K​ Thank you, it helped.

[Guillaume K]

The problem is finally solved by using STM32CubeProgrammer recently published version 2.12.0 .