search

pyocd / pyOCD

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

PyOCD cannot connect to ARM SWDAP probe with STM32F767ZI target. #771

Open kristofmulier opened 4 years ago

kristofmulier commented 4 years ago

I'm an OpenOCD defector, making my first steps in the world of PyOCD. But I can't get my microcontroller board to work. Please help.

1. Setup

1.1 Probe

I've got the official SWDAP probe from ARM (bought at L-Tek https://www.l-tek.com/web-shop/l-tek-swdap-interface/):

image

I flashed the latest 0254_lpc11u35_0x0000.bin DAPLink firmware to my probe (see https://github.com/ARMmbed/DAPLink/releases). So the SWDAP probe is up-to-date.  

1.2 Microcontroller board

I've got a self-made board with an STM32F767ZI microcontroller. The board is powered from a USB-micro connector (which is for power only, no data). I've got a 10-pin Cortex Debug connector for SWD flashing and debugging:

image

I connect the SWDAP probe to my board with the ribbon cable that was shipped with my SWDAP probe.  

1.3 Desktop

My desktop computer runs 64-bit Windows 10 with the latest Python 3.8. I just installed PyOCD today. I did not use pip install but I cloned the PyOCD GitHub and issued the command:

$ python setup.py install

So I got the latest development version of PyOCD. I also put the libusb dll next to python.exe in my Python 3.8 installation folder, as requested in the installation instructions.  

2. Running PyOCD

2.1 Find probe

First I check if PyOCD finds the probe:

$ pyocd list

      #   Probe              Unique ID
    ---------------------------------------------------------------------------
      0   ARM CMSIS-DAP v1   000000800a0c882800000000000000000000000097969902

So that seems allright.  

2.2 Download pack for STM32F767ZI

Unfortunately the STM32F767ZI microcontroller is not in the builtin targets. I issued the command pyocd list --targets and couldn't find it. So I download the corresponding pack Keil.STM32F7xx_DFP.2.12.0.pack from http://www.keil.com/dd2/pack/.  

2.3 Start GDB server

I issue the following command to make PyOCD connect to my microcontroller and start a GDB server:

pyocd gdbserver --target=stm32f767zi --pack="C:/ ... /packs/Keil.STM32F7xx_DFP.2.12.0.pack"

PyOCD immediately prints out:

    0000874:INFO:board:Target type is stm32f767zi

So I believe it's time to start the GDB client.  

2.4 Start GDB client

I open another Windows console, and issue the command:

$ arm-none-eabi-gdb

    (gdb) target remote localhost:3333
    localhost:3333: No connection could be made because the target machine actively refused it.
    (gdb)

I've got no luck here.

After a few seconds, I notice the following output in the first console (the one running PyOCD):

# Note: this is output from the first console - the one running PyOCD
# -------------------------------------------------------------------

0020877:CRITICAL:__main__:Read timed out
Traceback (most recent call last):
  File "C:\Python38\lib\site-packages\pyocd-0.23.1.dev10-py3.8.egg\pyocd\probe\cmsis_dap_probe.py", line 151, in open
    self._link.open()
  File "C:\Python38\lib\site-packages\pyocd-0.23.1.dev10-py3.8.egg\pyocd\probe\pydapaccess\dap_access_cmsis_dap.py", line 580, in open
    self._packet_count = self._protocol.dap_info(self.ID.MAX_PACKET_COUNT)
  File "C:\Python38\lib\site-packages\pyocd-0.23.1.dev10-py3.8.egg\pyocd\probe\pydapaccess\cmsis_dap_core.py", line 135, in dap_info
    resp = self.interface.read()
  File "C:\Python38\lib\site-packages\pyocd-0.23.1.dev10-py3.8.egg\pyocd\probe\pydapaccess\interface\pywinusb_backend.py", line 162, in read
    raise DAPAccessIntf.DeviceError("Read timed out")
pyocd.probe.pydapaccess.dap_access_api.DAPAccessIntf.DeviceError: Read timed out

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "C:\Python38\lib\site-packages\pyocd-0.23.1.dev10-py3.8.egg\pyocd\__main__.py", line 343, in run
    self._COMMANDS[self._args.cmd](self)
  File "C:\Python38\lib\site-packages\pyocd-0.23.1.dev10-py3.8.egg\pyocd\__main__.py", line 571, in do_gdbserver
    with session:
  File "C:\Python38\lib\site-packages\pyocd-0.23.1.dev10-py3.8.egg\pyocd\core\session.py", line 291, in __enter__
    self.open()
  File "C:\Python38\lib\site-packages\pyocd-0.23.1.dev10-py3.8.egg\pyocd\core\session.py", line 367, in open
    self._probe.open()
  File "C:\Python38\lib\site-packages\pyocd-0.23.1.dev10-py3.8.egg\pyocd\probe\cmsis_dap_probe.py", line 163, in open
    six.raise_from(self._convert_exception(exc), exc)
  File "<string>", line 3, in raise_from
pyocd.core.exceptions.ProbeError: Read timed out

 

3. Conclusion

I tried several times to get the connection working. But I keep getting the same 0020877:CRITICAL:__main__:Read timed out error (with the whole traceback after it). In fact, it doesn't matter if I do or don't start the GDB client. PyOCD throws this error after perhaps 10 or 20 seconds - no matter what I do.

Note: The problem is not related to my board. I've flashed this board successfully with other probes using OpenOCD. So the hardware is OK.

cederom commented 4 years ago

Hello @kristofmulier :-) I don't have this Target so not sure how to help here, sorry. Can you verify your setup with another Target that is known to work (i.e. K64 or nRF51/52) in the first place? :-)

kristofmulier commented 4 years ago

Hi @cederom , That's a good idea. So I need a board with such a microcontroller (the K64 or nRF51/52) and a 10-pin Cortex Debug Connector, such that I can connect it to my SWDAP.

  10-pin Cortex Debug Connector:

image

Where can I buy such a board? If you have a Farnell / Mouser / DigiKey number, that would be great :-)

flit commented 4 years ago

NXP FRDM-K64F board on Mouser

The traceback for the "Read timed out" error indicates that the first USB transaction is failing. I'll try to reproduce when I get a chance.

kristofmulier commented 4 years ago

Thank you @flit

cstratton commented 4 years ago

This appears to be the exact same situation you posted at https://electronics.stackexchange.com/questions/465577/daplink-firmware-doesnt-operate-with-openocd - if you are going to post an issue in multiple places, you should link to the previous instance and give the context that you gave there.

Specifically you should have shared here as you did on EESE the fact that this probe worked with your target and OpenOCD with its original firmware, broke when you flashed these binary firmwares you found online, was repaired when you went back to the original firmware, and then broke again because you insisted on using this series of firmware binaries without any actual justification such as a feature they could allegedly provide which the original could not. That the mystery firmware also does not work with PyOCD is not particularly surprising under the circumstances - the more interesting question would be if you have identified any tool with which it does work.

Especially in light of @flit's analysis that this is a USB timeout, what you are describing appears to be a difference in the USB protocol between what is commonly understood by tool authors to be how the protocol is supposed to work, versus what the firmware actually does - or possibly even a gross error in its implementation in this particular binary build - at this point we don't actually know that these generic builds actually have all the needed functionality to function as a probe linked in (or were ever even expected to work with this particular target chip) vs being something like CI build tests accidentally exposed to the public as a result of insufficient curation of the section of the open source project applicable to this particular probe.

If there is another tool with with this particular firmware does work, then to actually address this issue, it would be necessary to debug the USB communication between PyOCD (or OpenOCD) and the probe firmware. If there isn't another tool that works, then the greatest likelihood is that this series of firmware images is simply broken, at least with respect to the target chip you are interested in.

But given that the firmware for the probe is itself open source, efforts should also include examining the commit history of the probe's firmware, and building the probe firmware from source so that the functionality it is supposed to present is actually known, and perhaps debug output from the probe's point of view can be provided as well.

Alternately, you should at the very least run a USB packet capture of the attempt and attach that to your issue. If there is any tool that does work with this firmware, comparing a packet capture of that would be useful too.

And don't forget that you reported on EESE that you have a firmware for this probe which makes it work with this target chip with OpenOCD (and absent any hint otherwise, presumably with PyOCD as well), so this issue of incompatibility with a yet-unvalidated probe firmware is in no way blocking actual development work. It might be worth tackling as a curiosity, but it's not really a problem blocking anyone from getting work done since the original factory firmware does work.

Key questions:

1) When running its original factory firmware, does the probe work with PyOCD the way it was reported to work with OpenOCD? If so that would be a key change in behavior between probe firmware versions or with these particular downloaded binary builds thereof.

2) Is there any other tool (Keil, etc) with which the offered binary builds of 0252, 0253, or 0254 has been found to work? This would hint at if a change of behavior is a legitimate variation of the DAP protocol which both PyOCD and OpenOCD should probably catch up with, or if it might be a bug in this build or version which should be reported to the DAP project.

cederom commented 4 years ago

Hey @cstratton we had enough of your trolling on Electronics / StackExchange that ended up with a really ugly shitstorm involving blocks and portal admins interventions (@flit beware). Go away and stop bullying @kristofmulier. If you don't do this on purpose just be aware that it looks like this. We don't want this here. You also criticized me and my answers pointing to pyOCD as the solution, so what are you doing here? Not cool :-(

Kris mentioned in point 1.1 that he works on a stock firmware (0254_lpc11u35_0x0000.bin). We suggested environment verification by obtaining several boards that are known to work and report back. Let's wait for the results.

kristofmulier commented 4 years ago

@cstratton , I admit that your post here on GitHub is not aggressive (aside from a few subtleties). However, you were flagged on StackOverflow for being rude/unkind in your comments. Those flags have been accepted by the moderators, so you should have gotten a warning. Therefore, I ask you kindly to ignore me on fora like StackOverflow, GitHub, ... I don't like to be followed by you.

Thank you @cederom for your support. I've bought the LPC812-LPCXpresso Board (OM13053UL) board: https://be.farnell.com/nxp/om13053ul/evaluation-lpcxpresso-cortex-m0/dp/2254492

It has an LPC3154 interface chip to convert USB into JTAG. The target is the LPC812-TSSOP20 chip. However, you can break off the interface LPC3154-part from the target part. This way, I can actually test the target with my SWDAP probe :-)

cederom commented 4 years ago

@kristofmulier no worries you will get into point where things start working for you.. you are kind of good writer and explorer so document all those steps for people that will have first contact with our tools in future :-)

Please try first with something that is 100% known to work - for instance NXP FRDM-K64F - as suggested by @flit - you will have a working DAPLink and Target pair on a single board for verification if all is fine with your machine/environment/pc setup.. also you will have one-click-to-compile examples to use, compile, flash, and debug using MBED ONLINE COMPILER. Use those in the first place to see if things work as expected. Then you can modify and alter configurations of the hardware. Otherwise there may be 842932 different reasons for things not to work. Use stable base, that works, then small steps of changes, and verification after each one of them. Skipping too much will cause unpredictable and hard to track problems :-)

Here is a full list of supported boards by ARM MBED OS, pick some of them, preferably those which have lots of ready-to-use examples in MBED ONLINE COMPILER:

https://os.mbed.com/platforms/

For instance get one of there and follow "Basic Program Examples" section on below sites:

  1. $35 https://os.mbed.com/platforms/FRDM-K64F
  2. $50 https://os.mbed.com/platforms/Hexiwear/