search

pyocd / pyOCD

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

dapTransfer fails on an erased chip #51

Closed tkuyucu-nordicsemi closed 9 years ago

tkuyucu-nordicsemi commented 10 years ago

After doing a full chip erase (either by calling board.flash.eraseAll() or by other means), pyocd is unable to communicate with the boards. An operation such as board.flash.init() will either hang or casue a "SWD fault" in the function dapTransfer of cmsis_dap_core.pyc

Tested on nrf mkit and freescale kl25z boards.

ECNU3D commented 10 years ago

It looks like I also witness such a failure, but does it effect the pyOCD function?

2014-08-06 21:54 GMT+08:00 tkuyucu notifications@github.com:

After doing a full chip erase (either by calling board.flash.eraseAll() or by other means), pyocd is unable to communicate with the boards. An operation such as board.flash.init() will either hang or casue a "SWD fault" in the function dapTransfer of cmsis_dap_core.pyc

Tested on nrf mkit and freescale kl25z boards.

— Reply to this email directly or view it on GitHub https://github.com/mbedmicro/pyOCD/issues/51.

clemtaylor commented 10 years ago

Yes, I have had the same problem with the nrf51822. The problem seems to be triggered by giving the processor a chance to execute an erased reset vector. This doesn't happen when the part is erased then programmed in the same sequence. Holding down the reset button and waiting for the chip erase will trigger this problem.

I can recover from this using util/flash_nrf51822.py, however flash_nrf51822.py tool dies after flashing:

util/flash_nrf51822.py -v -i .../uartTest.hex 
INFO:root:DAP SWD MODE initialised
INFO:root:IDCODE: 0xBB11477
INFO:root:4 hardware breakpoints, 0 literal comparators
INFO:root:CPU core is Cortex-M0
flash hex file - .../uartTest.hex to nrf51822
INFO:root:Erase All
INFO:root:Prepare to write
128.000000 kbytes flashed in 32.129123 seconds ===> 3.985667 kbytes/s
Traceback (most recent call last):
  File "util/flash_nrf51822.py", line 183, in <module>
    adapter.uninit()
  File "/home/ctaylor/Stuff/nordic/pyOCD.nordic.git/pyOCD/board/board.py", line 57, in uninit
    self.target.resume()
  File "/home/ctaylor/Stuff/nordic/pyOCD.nordic.git/pyOCD/target/cortex_m.py", line 608, in resume
    if self.getState() != TARGET_HALTED:
  File "/home/ctaylor/Stuff/nordic/pyOCD.nordic.git/pyOCD/target/cortex_m.py", line 599, in getState
    dhcsr = self.readMemory(DHCSR)
  File "/home/ctaylor/Stuff/nordic/pyOCD.nordic.git/pyOCD/target/cortex_m.py", line 388, in readMemory
    return self.transport.readMem(addr, transfer_size)
  File "/home/ctaylor/Stuff/nordic/pyOCD.nordic.git/pyOCD/transport/cmsis_dap.py", line 139, in readMem
    [addr])
  File "/home/ctaylor/Stuff/nordic/pyOCD.nordic.git/pyOCD/transport/cmsis_dap_core.py", line 204, in dapTransfer
    raise ValueError('Transfer not completed')
ValueError: Transfer not completed
c1728p9 commented 9 years ago

I think #71 and #76 will help with this problem.

c1728p9 commented 9 years ago

Pull request #142 should fix further programming problems. Has anyone seen this problem lately? I erased both an nrf51 and k22f and was able to reconnect and program them without any problems. I also ran blank_test.py on both, which continuously erases and resets the boards and the test found no problems. I think this issue can be closed.