Well, it seems like I have read your mail very quickly ! mainly locking and unlocking works well too, you just need to perform an OBL Launch
$ telnet localhost 4444 ... > flash probe 0 device idcode = 0x10016497 (STM32WLEx - Rev 'unknown' : 0x1001 - Flash single-bank) RDP level 0 (0xAA) flash size = 256kbytes flash mode : single-bank flash 'stm32l4x' found at 0x08000000 > halt target halted due to debug-request, current mode: Thread xPSR: 0x41000000 pc: 0x1fff26d2 msp: 0x200014f0 > stm32l4x lock 0 > stm32l4x option_load 0 Fail reading CTRL/STAT register. Force reconnect stlink_dap_op_connect(reconnect) SWD DPIDR 0x6ba02477 Failed to write memory at 0xe00fffec stm32l4x option load completed. Power-on reset might be required stm32wlx.cpu: external reset detected > flash probe 0 device idcode = 0x10016497 (STM32WLEx - Rev 'unknown' : 0x1001 - Flash single-bank) RDP level 1 (0x00) flash size = 256kbytes flash mode : single-bank flash 'stm32l4x' found at 0x08000000 does this solve the issue ? BTW, the missing revision id should not harm any functionality in openocd. Le mer. 1 sept. 2021 à 22:40, Tarek BOCHKATI <tarekbouchk...@gmail.com> a écrit : > Hi Jeremy, > > Thank you for reporting the issue. I'm happy you are enjoying STM32 > support within OpenOCD :) > > Well, I have tried the following steps on the current master branch > ref: a098816a6557e5882bf088ab12a06b94934f30ce > > $ telnet localhost 4444 > ... > > > flash probe 0 > device idcode = 0x10016497 (STM32WLEx/WL5x - Rev 'unknown' : 0x1001) > RDP level 0 (0xAA) > flash size = 256kbytes > flash mode : single-bank > flash 'stm32l4x' found at 0x08000000 > > > > mdw 0x8000000 8 > 0x08000000: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff > ffffffff > > > > program /media/sf_vm-share/elfs/WL55JC-NUC/GPIO_IOToggle.axf > Unable to match requested speed 500 kHz, using 200 kHz > Unable to match requested speed 500 kHz, using 200 kHz > target halted due to debug-request, current mode: Thread > xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc > ** Programming Started ** > Adding extra erase range, 0x080011f0 .. 0x080017ff > ** Programming Finished ** > > mdw 0x8000000 8 > 0x08000000: 20000428 0800014d 08001009 08001001 08001005 0800015b 0800015d > 00000000 > > > The programming seems to work just fine. > > I have tried the same steps with the ref you specified > (3f1c15d2a718c9d417c859172f2b1736a769d822), and I have got the same good > results. > > In order to investigate the issue you are facing, could you please share > with us the debug log (with -d3) > also I would be interested in having your option bytes configuration. > > > Le mer. 1 sept. 2021 à 21:25, Jeremy Willden <jer...@constellationlabs.com> > a écrit : > >> OpenOCD Devs (and Tarek), >> >> I posed this question in the OpenOCD IRC channel and Oleksij Rempel >> suggested I ask you about this issue. I reviewed the Gerrit changes that >> are currently in process and perhaps this fix is already in the works but >> not yet merged into the main code base. If so, please let me know and I'll >> see if I can manually merge those changes in the meantime. >> >> I'm currently using commit 3f1c15d2a718c9d417c859172f2b1736a769d822 from >> the master branch of OpenOCD with an STM32WLxx family chip (in a LoRa-E5-HF >> module form SeeedStudio) but I cannot successfully unlock nor lock the >> flash. Based on logic analyzer captures, writes to FLASH_OPTKEYR and >> FLASH_KEYR are happening correctly, but there is not a corresponding write >> to the FLASH_CR register (just 8 reads), which is necessary to lock or >> unlock the flash. >> >> I can probably pull together an interim solution if you can point me to >> the general commits that have already fixed this issue. If this problem is >> not expected, I'm equipped to gather better information and assist in >> fixing it. >> >> Please let me know if I can help and if there is any assistance you can >> offer. I am assisting a client to put products into their manufacturing >> supply chain in the next few weeks and using Windows in their production >> environment is something we really want to avoid, so OpenOCD is a great >> fit. We already use OpenOCD for programming other STMicro parts and are >> very happy with it. >> >> Thank You >> Jeremy Willden >> Constellation Labs, LLC >> direct: 801-877-1101 >> main: 801-877-1132 >> mobile: 801-318-8531 >> http://constellationlabs.com >> HAM callsign: KG7JW (formerly KG7ELA) >> >