I have an unresponsive 3272-SIP module and wanted to bring it back to life flashing the proper .hex file using the UART method through the STM32Cube programmer. I naively thought that by buying everything from RAK, it would “just work”. I tested on another responsive module and it didn’t seem to work. After hours of searching, I ended up seeing this thread: RAK3172 Breakout UART Connection
So, as a summary of my understanding (please correct me if I’m wrong)
you are selling a single USB-UART converter which is RAKDAP1
you are advising to use RAKDAP1 to connect to UART for STM32Cube programmer as seen here and everywhere else on your documentation whenever an USB-UART converter is needed
you are saying, in the above thread that RAKDAP1 is NOT working for this use
Then I have tried flashing the unresponsive one through the RAKDAP1 with the SW pins but got the same problem as here:
Please note that for this one:
I have indeed installed the stm32wle5jcix target
I have connected the RST pin (also tried disconnected with the same results)
I have tried the erase before (with the same result “No ACK received”)
I have lost HOURS on this story. Please tell me I missed something and there is a solution, at least I will feel that my hours weren’t spent in vain.
Well, I might be blind or confused (or maybe for some reason we’re not seeing the same version of the page) but I don’t see it here
I’ll try again tomorrow but I’m pretty sure there was no wiring issue. But from other symptoms I’m seeing I think this unresponsive module might have been completely dead on arrival. As I explained in my first email, I didn’t try it on the responsive module as it’s the only one I have left for now and I don’t want to break it.
The updated docs is still on staging. It will be merge to main branch within the week.
Do you have RAK3172-SiP breakout board? The modules are tested in factory. In my experience, most of the issues related to none responsive serial ports are USB-UART or MCU-UART related. We have issues before on modules going to boot mode but it is fixed now on the latest firmware versions.
Thanks for 1. As for 2:
Yes, I have different modules but the ones directly at hand are 2 3172-SiP breakouts. I received them in February (ordered them in December but that’s another story…) and I think they had version 3.5.1. I just recently found time to deal with them.
One of them was working flawlessly directly and I could update the firmware to 4.0.5. The other one I never managed to get a single UART response through all the tools I tried (I think I tried everything by now except stlink) and I spent hours testing all possibilities with the same technical chain that I used for the other one. So I highly doubt it has to do with the technical chain involved. I think this module was simply dead on arrival. I’ve ordered an STLinkv2 to try and revive it but I honestly think it won’t work and it’s more for the sake of “trying everything before pronouncing the death” than a real hope it will resuscitate
I’ll post the results here once I get the STlink (probably in a few days).
Not to give you too much hope but since the firmware is not yet 4.x.x (issues of low version firmware are solvable by uploading the latest hex - of course assuming the silicon is not dead).
You can still try to revive it via UART bootloader of STM32WL using STM32CubeProgrammer (but you need to use different USB-UART converter - not RAKDAP1).
Some news: I had to SWD RAKDAP1 flash the « working part » because I had put a faulty sketch in it: it worked flawlessly.
That’s an additional indication the other module was dead on arrival. I’ll wait till the STLink arrives to confirm the death…
