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)
>>
>


Reply via email to