search

pyocd / pyOCD

Open source Python library for programming and debugging Arm Cortex-M microcontrollers
https://pyocd.io
Apache License 2.0
1.11k stars 477 forks source link

NUCLEO_WB55RG erase fails #811

Closed juhhov closed 4 years ago

juhhov commented 4 years ago

The same fail constantly occurs.

STLink version:

$ cat /mnt/pci-0000_00_14_0-usb-0_1_1_1_1-scsi-0_0_0_0/DETAILS.TXT 
Version: 0221
Build:   Aug 23 2019 16:24:56

Traceback:

$ pyocd --version
0.24.1
$ pyocd erase -vvv -u 066CFF313335415043204530 -t stm32wb55rgvx --pack ~/workspace/raas-daemon/cmsis-packs/Keil.STM32WBxx_DFP.1.0.0.pack --chip
0000331:DEBUG:session:Project directory: /home/raas/pyOCD
0000340:DEBUG:pack_target:Loading target 'stm32wb55ccux' from CMSIS-Pack
0000340:DEBUG:pack_target:Loading target 'stm32wb55ceux' from CMSIS-Pack
0000340:DEBUG:pack_target:Loading target 'stm32wb55cgux' from CMSIS-Pack
0000340:DEBUG:pack_target:Loading target 'stm32wb55rcvx' from CMSIS-Pack
0000340:DEBUG:pack_target:Loading target 'stm32wb55revx' from CMSIS-Pack
0000340:DEBUG:pack_target:Loading target 'stm32wb55rgvx' from CMSIS-Pack
0000340:DEBUG:pack_target:Loading target 'stm32wb55vcyx' from CMSIS-Pack
0000340:DEBUG:pack_target:Loading target 'stm32wb55veyx' from CMSIS-Pack
0000340:DEBUG:pack_target:Loading target 'stm32wb55vgyx' from CMSIS-Pack
0000350:INFO:board:Target type is stm32wb55rgvx
0000355:DEBUG:stlink:STLink probe 066CFF313335415043204530 firmware version: V2J35M26
0000356:DEBUG:sequencer:Running task load_svd
0000412:DEBUG:sequencer:Running task create_flash
0000412:DEBUG:sequencer:Running task pre_connect
0000412:DEBUG:sequencer:Running task dp_init
0000437:DEBUG:dap:Default wire protocol selected; using SWD
0000448:INFO:dap:DP IDR = 0x6ba02477 (v2 rev6)
0000464:DEBUG:sequencer:Running task power_up
0000522:DEBUG:sequencer:Running task find_aps
0000530:DEBUG:sequencer:Running task create_aps
0000530:DEBUG:sequencer:Running task create_ap.0
0000533:DEBUG:ap:Using accelerated memory access interface
0000533:INFO:ap:AP#0 IDR = 0x24770011 (AHB-AP var1 rev2)
0000535:DEBUG:ap:AP#0 default HPROT=3 HNONSEC=0
0000537:DEBUG:ap:AP#0 implemented HPROT=3 HNONSEC=0
0000541:DEBUG:sequencer:Running task create_ap.1
0000544:DEBUG:ap:Using accelerated memory access interface
0000544:INFO:ap:AP#1 IDR = 0x84770001 (AHB-AP var0 rev8)
0000546:DEBUG:ap:AP#1 default HPROT=3 HNONSEC=1
0000548:DEBUG:ap:AP#1 implemented HPROT=f HNONSEC=1
0000554:DEBUG:sequencer:Running task find_components
0000554:DEBUG:sequencer:Running task init_ap.0
0000569:INFO:rom_table:AP#0 ROM table #0 @ 0xe00ff000 (designer=020 part=495)
0000583:INFO:rom_table:[0]<e000e000:SCS-M4 class=14 designer=43b part=00c>
0000593:INFO:rom_table:[1]<e0001000:DWT class=14 designer=43b part=002>
0000601:INFO:rom_table:[2]<e0002000:FPB class=14 designer=43b part=003>
0000610:INFO:rom_table:[3]<e0000000:ITM class=14 designer=43b part=001>
0000619:INFO:rom_table:[4]<e0040000:TPIU-M4 class=9 designer=43b part=9a1 devtype=11 archid=0000 devid=0:0:ca1>
0000628:INFO:rom_table:[5]<e0041000:ETM-M4 class=9 designer=43b part=925 devtype=13 archid=0000 devid=0:0:0>
0000638:INFO:rom_table:[6]<e0043000:CTI class=9 designer=43b part=906 devtype=14 archid=0000 devid=0:0:40800>
0000638:DEBUG:sequencer:Running task create_cores
0000638:DEBUG:coresight_target:Creating SCS-M4 component
0000642:INFO:cortex_m:CPU core #0 is Cortex-M4 r0p1
0000657:INFO:cortex_m:FPU present: FPv4-SP
0000660:DEBUG:sequencer:Running task set_default_reset_type
0000660:DEBUG:sequencer:Running task create_components
0000661:DEBUG:coresight_target:Creating DWT component
0000666:INFO:dwt:4 hardware watchpoints
0000678:DEBUG:coresight_target:Creating FPB component
0000681:INFO:fpb:6 hardware breakpoints, 4 literal comparators
0000684:DEBUG:fpb:fpb has been disabled
0000698:DEBUG:coresight_target:Creating ITM component
0000708:DEBUG:coresight_target:Creating TPIU-M4 component
0000711:DEBUG:sequencer:Running task check_for_cores
0000711:DEBUG:sequencer:Running task halt_on_connect
0000711:DEBUG:cortex_m:halting core 0
0000714:DEBUG:sequencer:Running task post_connect
0000714:DEBUG:sequencer:Running task notify
0000714:INFO:eraser:Erasing chip...
0000714:DEBUG:cortex_m:halting core 0
0000717:DEBUG:cortex_m:set reset catch, core 0
0000717:DEBUG:cortex_m:halting core 0
0000724:DEBUG:cortex_m:reset, core 0, type=SW_SYSRESETREQ
0000745:DEBUG:cortex_m:clear reset catch, core 0
0000847:DEBUG:cortex_m:resuming core 0
0000847:DEBUG:manager:added=[] removed=[]
0000847:DEBUG:manager:bps after flush={}
0000879:DEBUG:cortex_m:resuming core 0
0000879:DEBUG:manager:added=[] removed=[]
0000879:DEBUG:manager:bps after flush={}
0000894:DEBUG:session:uninit session <pyocd.core.session.Session object at 0x7f3186bd9390>
0000895:DEBUG:board:uninit board <pyocd.board.mbed_board.MbedBoard object at 0x7f318a6c8ac8>
0000900:DEBUG:cortex_m:cannot resume: target not halted
0000908:CRITICAL:__main__:erase_all error: 536871425
Traceback (most recent call last):
  File "/home/raas/pyOCD/py3/lib/python3.5/site-packages/pyocd/__main__.py", line 344, in run
    self._COMMANDS[self._args.cmd](self)
  File "/home/raas/pyOCD/py3/lib/python3.5/site-packages/pyocd/__main__.py", line 505, in do_erase
    eraser.erase(addresses)
  File "/home/raas/pyOCD/py3/lib/python3.5/site-packages/pyocd/flash/eraser.py", line 76, in erase
    self._chip_erase()
  File "/home/raas/pyOCD/py3/lib/python3.5/site-packages/pyocd/flash/eraser.py", line 98, in _chip_erase
    region.flash.erase_all()
  File "/home/raas/pyOCD/py3/lib/python3.5/site-packages/pyocd/flash/flash.py", line 338, in erase_all
    raise FlashEraseFailure('erase_all error: %i' % result, result_code=result)
pyocd.core.exceptions.FlashEraseFailure: erase_all error: 536871425
flit commented 4 years ago

@juhhov Do you have an extra WB55 board you could send to me?

jeromecoutant commented 4 years ago

Hi

Note that STM32WB chips are dual core MCU:

FLASH is shared for both cores.

See Reference Manual: https://www.st.com/resource/en/reference_manual/dm00318631.pdf

3.3.7 Flash main memory erase sequences
Flash memory mass erase
A Flash memory mass erase by the CPU1 is ignored and a bus error is generated
jeromecoutant commented 4 years ago

@MarceloSalazar @schstm

flit commented 4 years ago

@jeromecoutant You may have found the issue. Currently, pyocd will always use the first CPU (lowest AP) for flash programming operations. It needs to be extended to honour the Pname attribute of the PDSC <algorithm> element.

What I don't understand, though, is that the reported error (0x20000201) was returned by the EraseChip() API. In other words, it doesn't appear that a bus error occurred.

flit commented 4 years ago

Fyi, I should be receiving a WB55 board on Monday (thanks @juhhov!) and can work on a fix.

RomanSaveljev commented 4 years ago

hi @flit did you receive the board? Do you need something else from us to help?

VeijoPesonen commented 4 years ago

@jeromecoutant so with the current CMSIS-Pack it's also not possible to execute full flash erase succesfully with Keil MDK:

image

jeromecoutant commented 4 years ago

I don't think it is a question of CMSIS-Pack ?

See above comments, it is defined in the chip deference manual.

VeijoPesonen commented 4 years ago

The PDSC file seems to talk about M4, not about M0 (CMSIS/Flash/STM32WB_M4.FLM - information hidden also to the bottom-left corner of the picture I attached):

PDSC file - part of CMSIS-Pack

<!-- *************************  Device 'STM32WB55RG'  ***************************** -->
<device Dname="STM32WB55RGVx">
<memory id="IROM1"                           start="0x08000000" size="0x00100000" startup="1" default="1" />
<memory id="IRAM1"                           start="0x20000000" size="0x00040000" init="0"    default="1" />
<algorithm name="CMSIS/Flash/STM32WB_M4.FLM" start="0x08000000" size="0x00100000"             default="1" />
<feature type="QFP" n="68"/>
</device>

CMSIS-Packs\Keil\STM32WBxx_DFP\1.1.0\Keil.STM32WBxx_DFP.pdsc

@jeromecoutant In other words if there is no flash algorithm for M0 is there need to have one? The sources are there but compiled binaries for M0Plus are missing. But I guess the same works for both cores:

#elif defined STM32WB_M4       /* 2 * 128 kB  or 1 * 256 kB*/
  #define FLASH_BANK_SIZE       (0x08020000U)
#elif defined STM32WB_M0Plus       /* 2 * 128 kB  or 1 * 256 kB*/
  #define FLASH_BANK_SIZE       (0x08020000U)

Are CM0 SVD files missing for WB55? image

VeijoPesonen commented 4 years ago

@jeromecoutant CPU2 security (ESE) is enabled by default and needs to disabled explicitly?

jeromecoutant commented 4 years ago

But why do you want to erase full flash, you will loose BLE FW!!? Note if you are not interested in BLE, you should choose another STM32 chip...

VeijoPesonen commented 4 years ago

But why do you want to erase full flash, you will loose BLE FW!!?

How you're actually supposed to update the BLE firmware?

jeromecoutant commented 4 years ago

Very specific procedure! Check https://github.com/ARMmbed/mbed-os/blob/master/targets/TARGET_STM/TARGET_STM32WB/README.md

VeijoPesonen commented 4 years ago

In this case there is 812KiB for application software, the rest 212KiB is reserved by the BLE firmware.

pyocd erase -s 0x08000000-0x080CB000
0001122:INFO:eraser:Erasing sector 0x08000000 (4096 bytes)
0001173:INFO:eraser:Erasing sector 0x08001000 (4096 bytes)
...
0011320:INFO:eraser:Erasing sector 0x080c9000 (4096 bytes)
0011365:INFO:eraser:Erasing sector 0x080ca000 (4096 bytes)

Restrictions to flash usage

The STM32WB55xx devices feature a single physical address space that can be accessed by the application processor and by the RF subsystem. A part of the Flash memory and of the SRAM2a and SRAM2b memories are made secure, exclusively accessible by the CPU2, protected against execution, read and write from CPU1 and DMA. In case of shared resources the SW should implement arbitration mechanism to avoid access conflicts. This happens for peripherals Reset and Clock Controller (RCC), Power Controller (PWC), EXTI and Flash interface, and can be implemented using the built-in semaphore block (HSEM). By default the RF subsystem and CPU2 operate in secure mode. This implies that part of the Flash and of the SRAM2 memories can only be accessed by the RF subsystem and by the CPU2. In this case the Host processor (CPU1) has no access to these resources.

STM32WB55xx Datasheet, Chapter 5.

VeijoPesonen commented 4 years ago

@juhhov I assume this issue can be closed.