Hi guys,
I’m have trouble using cube programmer to erase the native at-firmware from wio-e5 mini.
I’m able to connect with serial to use the at command but when I open the cube programmer, no device is detected.
I couldn’t find any document detailing what to do.
does anyone else have the similar problem?
Can someone help please?
Thank you very much.
Hello, how did you connect it to the computer, and can you provide the wiring diagram?
It is not enough just to power the STM32Cube via USB-C. If you want to develop with the STM32Cube, you also need to prepare an ST-link as described in the Wiki above and connect it to the PC via the SWD pin.
I’ve just received two of these devices in the post. It’s interesting to me that it was marketed as a dev board at all.
This is a product that ships with read protected firmware and no way to erase/program it via USB. Easily flashing via USB is really the feature which makes a product a “dev” board, as you can flash just about anything with an ST MCU if you have an SWD/JTAG programmer, which is what this board requires. And then if you do go through the effort of removing the RDP with an st-link (a seperate purchase) you can’t restore the original AT firmware. To top it off, you still can’t reliably use the ST boot loader to flash via USB as they haven’t broken out the BOOT0 pin. Meaning you have to hook up SWD again!
Wish I’d done more research before purchasing as I feel misled about what I was actually getting. I see Seeed has plainly explained this in their docs, but frankly, it just shouldn’t have been done like this and marketed the way it is. It’s a LoRa module.
Unfortunatly it happens all the time…
Hi there,
I would agree with the OP on the DEV classification, 
I think Seeed maybe was misled by the creator or chip supplier on the NON-Open Source of the bootloader , from which everything and anything is possible. The Whole AT firmware Malarky is just a barrier to True development on these platforms, is it me or do things seem to becoming more closed in LORA and proprietary than before, IDK ? SMH on this one.
My.02
GL 
PJ 
yes there is something secret about the AT firmware that is propritary or something… i guess if someone pays you to make a model T ford… you make a model T ford… What Da?
i am also facing same problem actually i used stlinkv2 to erase the frimware and after some time my board is not able to connect with the cube programming i connected every wire properly but still it is showing “No stm32 target found! if your product embeds debug authentication, please perform a discovery using debug authentication”. if you any of you faced this issue kindly reply
Hi there,
SO , this is a common issue. It means your programming or debugging tool cannot establish a connection with the target STM32 microcontroller.
The second part of the message suggests that a security feature called Debug Authentication might be enabled, which requires a specific procedure to access the device’s debug interface.
Understanding the Error and Authentication
The “No target found” error is common and usually stems from physical connection issues, incorrect software settings, or a locked chip. The tool you are using (like STM32CubeProgrammer or an IDE) tries to connect via a debug interface (SWD or JTAG) but fails to detect a responding STM32 chip.
Debug Authentication is a security scheme that prevents unauthorized access to the device’s restricted parts. If the chip you are trying to connect to has this feature enabled (either by default on some models or intentionally by previous programming), the standard connection methods will fail, and the software prompts you to use the specific “discovery” procedure to unlock it with the correct credentials.
Furthermore, if you read the wiki about erasing the AT command set capability there is no Factory Flash or J-tagable rom image available due to the Proprietary nature of the code. I have seen in the wild some AT command clones, perhaps something like that is available. YMMV 
HTH
GL 
PJ 
Hello,
Thanks for the clarification. I have one more question so I can avoid repeating this issue on a new board.
Is there any safe or officially supported method for flashing custom firmware onto the Wio-E5 Mini board?
From what I understand now:
The Wio-E5 Mini doesn’t expose BOOT0, so DFU bootloader mode cannot be used.
If the AT firmware is erased or SWD settings get corrupted, the module becomes unrecoverable because Debug Authentication locks the chip.
Since the original AT firmware is proprietary and not available publicly, it cannot be restored once overwritten.
Before I purchase another board, I want to confirm:
Can we safely program custom firmware on a Wio-E5 Mini at all, or is it only meant to be used as an AT command modem?
If there is a safe workflow (special settings, firmware template, correct Option Bytes, etc.), please let me know.
This will help me decide whether to replace the board or move to a different STM32WL development kit that exposes BOOT0/SWD fully.
Thanks in advance for any guidance.
