Cannot run STM32 L1 Discovery board - stm32

I have fresh STM32 L1 discovery board, and it seems to be broken.
But I am not completely sure.
When connecting board via USB to the Linux machine, board starts
perfectly fine, and the demo works just as described by vendor.
But I am unable to actually connect to this board.
➜ lsusb -s 002:074
Bus 002 Device 074: ID 0483:3748 STMicroelectronics ST-LINK/V2
Board seems to be connected, big jumper (CN3) to switch between ST-LINK and DISCOVERY is set to DISCOVERY. But when I try to use st-link utility
I am receiving.
➜ stlink git:(master) ./st-flash --reset erase
libusb_handle_events() timeout
[!] send_recv
libusb_submit_transfer(-6)
[!] send_recv
libusb_submit_transfer(-6)
[!] send_recv
libusb_submit_transfer(-6)
[!] send_recv
libusb_submit_transfer(-6)
[!] send_recv
2015-12-25T19:24:57 INFO src/stlink-common.c: Loading device parameters....
libusb_submit_transfer(-6)
[!] send_recv
libusb_submit_transfer(-6)
[!] send_recv
libusb_submit_transfer(-6)
[!] send_recv
2015-12-25T19:24:57 WARN src/stlink-common.c: unknown chip id! 0
fish: Job 1, './st-flash --reset erase' terminated by signal SIGSEGV (Address boundary error)
Also OpenOCD is unable to talk to the board.
openocd -f board/stm32ldiscovery.cfg
Open On-Chip Debugger 0.9.0 (2015-12-25-18:43)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
adapter speed: 300 kHz
adapter_nsrst_delay: 100
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
none separate
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : Unable to match requested speed 300 kHz, using 240 kHz
Info : Unable to match requested speed 300 kHz, using 240 kHz
Info : clock speed 240 kHz
Error: reset device failed
in procedure 'init'
in procedure 'ocd_bouncer'
The chip on board is STM32L152RCT6. I worked with STM32F0..4 before and had never such problems, but I did not worked with L series before, so I am not sure if this is board problem or I am skipping something important here.
EDIT: Using OpenOCD i found out not expected behaviour. At first run I am receiving error:
Error: init mode failed (unable to connect to the target)
At second run:
Error: reset device failed
Then device dissapears from the system, dmesg leaves messages:
[ 1336.080239] usb 2-1.1: reset full-speed USB device number 4 using ehci-pci
[ 1336.154250] usb 2-1.1: device descriptor read/64, error -32
[ 1336.329341] usb 2-1.1: device descriptor read/64, error -32
[ 1336.503334] usb 2-1.1: reset full-speed USB device number 4 using ehci-pci
[ 1336.566330] usb 2-1.1: device descriptor read/64, error -32
[ 1336.741385] usb 2-1.1: device descriptor read/64, error -32
[ 1336.915427] usb 2-1.1: reset full-speed USB device number 4 using ehci-pci
[ 1337.317517] usb 2-1.1: device not accepting address 4, error -32
[ 1337.390532] usb 2-1.1: reset full-speed USB device number 4 using ehci-pci
[ 1337.792623] usb 2-1.1: device not accepting address 4, error -32
[ 1337.793110] usb 2-1.1: USB disconnect, device number 4
[ 1337.855642] usb 2-1.1: new full-speed USB device number 5 using ehci-pci
[ 1337.918651] usb 2-1.1: device descriptor read/64, error -32
[ 1338.093691] usb 2-1.1: device descriptor read/64, error -32
[ 1338.267730] usb 2-1.1: new full-speed USB device number 6 using ehci-pci
[ 1338.330727] usb 2-1.1: device descriptor read/64, error -32
[ 1338.505783] usb 2-1.1: device descriptor read/64, error -32
[ 1338.679823] usb 2-1.1: new full-speed USB device number 7 using ehci-pci
[ 1339.081921] usb 2-1.1: device not accepting address 7, error -32
[ 1339.154935] usb 2-1.1: new full-speed USB device number 8 using ehci-pci
[ 1339.557024] usb 2-1.1: device not accepting address 8, error -32
[ 1339.557168] usb 2-1-port1: unable to enumerate USB device
I think there might be a problem with adapter speed, but I am not sure for now.
EDIT2: I tried with Windows ST Link Utility and I am not able to connect to the board, board causing "Detection Error" or "Connection Error", software suggests changing SWD frequency or mode. I tired with literally every combination but none works.
EDIT3: If this helps somebody, board was sent back, I have got information that it is actually broken and I have got new one. New one works flawlessly as expected.

Sometimes I work with the same L1 Discovery board on GNU/Linux. Both texane/stlink and OpenOCD detect it flawlessly without any modification. You can see the outputs:
$ st-util
2016-01-08T21:55:59 INFO src/stlink-common.c: Loading device parameters....
2016-01-08T21:55:59 INFO src/stlink-common.c: Device connected is: L1 Med-density device, id 0x10186416
2016-01-08T21:55:59 INFO src/stlink-common.c: SRAM size: 0x4000 bytes (16 KiB), Flash: 0x20000 bytes (128 KiB) in pages of 256 bytes
2016-01-08T21:55:59 INFO gdbserver/gdb-server.c: Chip ID is 00000416, Core ID is 2ba01477.
2016-01-08T21:55:59 INFO gdbserver/gdb-server.c: Target voltage is 2917 mV.
2016-01-08T21:55:59 INFO gdbserver/gdb-server.c: Listening at *:4242...
$ openocd -f board/stm32ldiscovery.cfg
GNU ARM Eclipse 64-bits Open On-Chip Debugger 0.10.0-dev-00141-g09aeb96-dirty (2015-10-28-11:56)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
adapter speed: 300 kHz
adapter_nsrst_delay: 100
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
none separate
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : Unable to match requested speed 300 kHz, using 240 kHz
Info : Unable to match requested speed 300 kHz, using 240 kHz
Info : clock speed 240 kHz
Info : STLINK v2 JTAG v25 API v2 SWIM v0 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 2.913980
Info : stm32l1.cpu: hardware has 6 breakpoints, 4 watchpoints
Maybe your board is really broken but before recycle it I suggest you two different trials. (a) I think after your question you have another ST (as you mentioned STM32F0..4) board perhaps with ST-LINK adaptor. You can use it as an external ST-LINK (follow eg. this). (b) Try to upgrade your embedded ST-LINK firmware with the STSW-LINK005 which java version works also in GNU/Linux environment. The board performs well for me both before and after upgrade.

Related

Debugging USB serial disconnection on raspberry pi

On one of my raspberry pis (Raspbian OS) with a USB serial device connected, there is periodic disconnection of the serial device while still being registered as a USB device.
lsusb returns a valid Bus Device entry, but there is no corresponding /dev/serial/ entry.
The only way to fix this issue is rebooting the pi, which I'd like to avoid.
I'd love some ideas on how I can debug USB serial connections on a Raspberry Pi Linux platform, or methods to reset the serial connection without requiring a reboot.
We tried:
Tracking udevadm monitor to see USB related events. This is what is seen where we catch a serial disconnection / reconnection happening:
KERNEL[65879.184887] remove /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/tty/ttyACM1 (tty)
KERNEL[65879.185179] remove /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0 (usb)
KERNEL[65879.185389] remove /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.1 (usb)
KERNEL[65879.185728] remove /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.2 (usb)
KERNEL[65879.186275] remove /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3 (usb)
UDEV [65879.193792] remove /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.1 (usb)
UDEV [65879.197016] remove /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/tty/ttyACM1 (tty)
UDEV [65879.197414] remove /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.2 (usb)
UDEV [65879.203665] remove /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0 (usb)
UDEV [65879.205795] remove /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3 (usb)
==> /var/log/messages <==
Jan 20 18:36:42 rpi4161a-172-101 kernel: [65879.307684] usb 1-1.3: USB disconnect, device number 12
==> /var/log/syslog <==
Jan 20 18:36:42 rpi4161a-172-101 kernel: [65879.307684] usb 1-1.3: USB disconnect, device number 12
KERNEL[65880.121912] add /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3 (usb)
KERNEL[65880.122424] add /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0 (usb)
KERNEL[65880.125157] add /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/tty/ttyACM0 (tty)
KERNEL[65880.125702] add /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.1 (usb)
KERNEL[65880.126324] add /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.2 (usb)
UDEV [65880.158159] add /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3 (usb)
UDEV [65880.167588] add /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0 (usb)
UDEV [65880.168004] add /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.1 (usb)
UDEV [65880.169128] add /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.2 (usb)
UDEV [65880.177534] add /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/tty/ttyACM0 (tty)
==> /var/log/messages <==
Jan 20 18:36:43 rpi4161a-172-101 kernel: [65880.244987] usb 1-1.3: New USB device found, idVendor=****, idProduct=****, bcdDevice= 1.00
Jan 20 18:36:43 rpi4161a-172-101 kernel: [65880.245001] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jan 20 18:36:43 rpi4161a-172-101 kernel: [65880.245010] usb 1-1.3: Product: J-Link Pro OB
Jan 20 18:36:43 rpi4161a-172-101 kernel: [65880.245020] usb 1-1.3: Manufacturer: ****
Jan 20 18:36:43 rpi4161a-172-101 kernel: [65880.245028] usb 1-1.3: SerialNumber: ****
Jan 20 18:36:43 rpi4161a-172-101 kernel: [65880.248227] cdc_acm 1-1.3:1.0: ttyACM0: USB ACM device
Jan 20 18:36:43 rpi4161a-172-101 mtp-probe: checking bus 1, device 13: "/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3"
Jan 20 18:36:43 rpi4161a-172-101 mtp-probe: bus: 1, device: 13 was not an MTP device
Checking if the raspberry pi was overheating, using vcgencmd. It returns 8000 Soft temperature limit has occurred flag sometimes, but not always.
Tried the following method to "reset" the serial connection, which had no effect
echo -n '1-1.3:1.0' | sudo tee -a unbind
echo -n '1-1.3:1.0' | sudo tee -a bind
Followed some of the solutions here: https://raspberrypi.stackexchange.com/questions/9264/how-do-i-reset-a-usb-device-using-a-script, including the solution to reset the USB bus, with no luck.
USB Serial malfunctioning may be caused by many different factors, including software, hardware or noisy environment.
The following diagram roughly describes the related components,
-------------------- ----------------
| Userspace (Apps) | | Power Supply |
-------------------- ----------------
^
|
-------------------- ------------- ----------
| Kernel (Drivers) | <-- | USB Cable | <-- | Device |
-------------------- ------------- ----------
Narrow down to the faulty part
As first step, elimination method can help us to narrow down to the faulty part, basically you replace the suspect part with another good component, and observe if it changes result. for example,
use the latest official raspbian image to eliminate userspace issue
choose a different kernel/firmware image to eliminate kernel/driver issue
change usb cable
change usb device
use a decent power supply
Troubleshooting on software issue
Assume we could narrow down the scope to software, I would use the following procedures to do further check,
Make sure the usb device is recognized by kernel, check with lsusb, dmsg, udevadm.
Have a correct name (dev path), check udev rules;
Run udevadm monitor to observe any unexpected disconnection events, make sure it works (stable connection) on a fresh OS image, and install only necessary packages step by step.
Other tips
Check if your usb device is a "smart" device? meaning the device may have its own logic to disconnect or change mode, so that affect your host side connection.
To see what happened on the USB bus it is better to use usbmon (see https://wiki.wireshark.org/CaptureSetup/USB).
I think you should carefully check usb descriptors: lsusb -v and check how much current it attempts to take (check configuration descriptor: https://learn.microsoft.com/en-us/windows-hardware/drivers/usbcon/usb-configuration-descriptors).
I think reconnects could occur due to insufficient current to you usb device especially if device supplied only from bus. If current > than usb host controller can provide, usb host-controller limits current this could lead to device reset. To check this hypothesis connect your device to Raspberry using active hub with external power supply.

stlink-org / 1.6.1 / STM32F723 / Raspberry Pi4

I have a problem with flashing proc using https://github.com/stlink-org.
Using windows STM32-Utility all works fine on every programer.
I also using debug which works correctly
Tried on other version v1.6.1.8x or 1.5.1 - this same problem
My setup:
Raspbbery Pi 4 with NOOBs
STM32F723, also i tried on Nucleo programer and ST-LINK / V2
stlink version - v1.6.1-201-g4bfaab0
At this moment I can erase memory, but that's all. When I tried to flash it crashes.
./st-flash write test.bin 0x8000000
------------------------------------
2021-02-05T10:26:04 INFO common.c: Flash page at addr: 0x08011480 erased
2021-02-05T10:26:04 INFO common.c: Flash page at addr: 0x08011500 erased
2021-02-05T10:26:04 INFO common.c: Flash page at addr: 0x08011580 erased
2021-02-05T10:26:04 INFO common.c: Flash page at addr: 0x08011600 erased
2021-02-05T10:26:04 INFO common.c: Flash page at addr: 0x08011680 erased
2021-02-05T10:26:04 INFO common.c: Flash page at addr: 0x08011700 erased
2021-02-05T10:26:04 INFO common.c: Finished erasing 559 pages of 128 (0x80) bytes
2021-02-05T10:26:04 INFO common.c: Starting Flash write for L0
2021-02-05T10:26:04 INFO common.c: Starting Half page flash write for STM32L core id
2021-02-05T10:26:04 INFO flash_loader.c: Successfully loaded flash loader in sram
2021-02-05T10:26:04 INFO common.c: Go to Thumb mode
2021-02-05T10:26:05 ERROR flash_loader.c: Flash loader run error (R2 0xF1000003 R15 0xF1000003 DHCSR 0x01080001 DFSR 0x0000000B)
2021-02-05T10:26:05 WARN common.c: l1_stlink_flash_loader_run(0x8000000) failed! == -1
2021-02-05T10:26:05 WARN common.c:
write_half_pages failed == -1
^C[!] send_recv send request failed: LIBUSB_ERROR_BUSY
[!] send_recv STLINK_DEBUG_READREG
2021-02-05T10:26:16 INFO common.c: Go to Thumb mode
[!] send_recv send request failed: LIBUSB_ERROR_BUSY
[!] send_recv STLINK_DEBUG_WRITEREG
[!] send_recv send request failed: LIBUSB_ERROR_BUSY
[!] send_recv STLINK_JTAG_WRITEDEBUG_32BIT
[!] send_recv send request failed: LIBUSB_ERROR_BUSY
[!] send_recv STLINK_JTAG_WRITEDEBUG_32BIT
lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 060: ID 0483:374f STMicroelectronics STLINK-V3
Bus 001 Device 007: ID 046d:c534 Logitech, Inc. Unifying Receiver
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
./st-info --probe
Found 1 stlink programmers
version: V3J7S1
serial: 303034343030333033303339353130353334333933383338
hla-serial: "\x30\x30\x34\x34\x30\x30\x33\x30\x33\x30\x33\x39\x35\x31\x30\x35\x33\x34\x33\x39\x33\x38\x33\x38"
flash: 196608 (pagesize: 128)
sram: 20480
chipid: 0x0447
descr: L0xx Category 5

Unable to install and configure a J-Link JTAG debugger on a Mac

I have a Segger J-Link which I am trying to use on a Macbook running MacOS Catalina 10.15.4, with openocd and GDB against an ESP32 board. The problem is that I can not seen the device:
$ ls /dev/cu.*
/dev/cu.Bluetooth-Incoming-Port /dev/cu.JimsiPhone-WirelessiAP /dev/cu.SLAB_USBtoUART /dev/cu.usbserial-0001
None of these is the J-Link. If I run lsusb I can see it:
$ lsusb
Bus 020 Device 002: ID 10c4:ea60 Cygnal Integrated Products, Inc. CP210x UART Bridge / myAVR mySmartUSB light
Bus 020 Device 003: ID 1366:0101 SEGGER J-Link ARM
I have installed the "J-Link Software and Documentation Pack" downloaded from Segger. I have checked the Mac "Security and privacy" settings and it does not report that it blocked any drivers or programs from being installed or run.
On the J-Link, the green LED is on, with a very brief flash about twice per second.
I'm sure I have a piece missing, and would appreciate some help.
UPDATE: I have been following instructions here:
OpenOCD Instructions
It all works until I get to step 6, and I follow these instructions:
Serial driver instructions
The problem is, a path for the driver never shows up, as I described above. I don't think I can run OpenOCD if I can't make it talk to my J-link.
When I run openocd-esp32, I get (full paste from openocd-esp32 output is below):
Error: No J-Link device found.
The contents of esp32-wroom-32.cfg is:
echo "WARNING: boards/esp-wroom-32.cfg is deprecated, and may be removed in a future release."
set ESP32_FLASH_VOLTAGE 3.3
source [find target/esp32.cfg]
Here is the full paste:
Jims-MacBook-Pro-486:~ jim$ openocd -f interface/jlink.cfg -f board/esp-wroom-32.cfg -c "program_esp32 build/hello-world.bin 0x10000 verify exit"
Open On-Chip Debugger v0.10.0-esp32-20200420 (2020-04-20-16:15)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
WARNING: boards/esp-wroom-32.cfg is deprecated, and may be removed in a future release.
Info : Configured 2 cores
Error: No J-Link device found.
** OpenOCD init failed **
shutdown command invoked
Assertion failed: (jtag_trst == 0), function jtag_checks, file src/jtag/core.c, line 343.
Abort trap: 6
Running JLinkExe does find the J-Link:
Jims-MacBook-Pro-486:~ jim$ JLinkExe
SEGGER J-Link Commander V6.80b (Compiled Jun 5 2020 17:42:04)
DLL version V6.80b, compiled Jun 5 2020 17:41:46
Connecting to J-Link via USB...Updating firmware: J-Link V11 compiled Apr 23 2020 16:49:23
Replacing firmware: J-Link V11 compiled Aug 14 2019 16:21:09
Waiting for new firmware to boot
New firmware booted successfully
O.K.
Firmware: J-Link V11 compiled Apr 23 2020 16:49:23
Hardware version: V11.00
S/N: 51000936
License(s): GDB
VTref=0.000V
Type "connect" to establish a target connection, '?' for help
J-Link>
After doing the above I now get a different error message when running openocd-esp32 (perhaps because of the J-Link FW upgrade?). Initially it complained that there was not an adapter speed set, so I modified interface/jlink.cfg and added:
adapter_khz 3000
I now get a different error:
Error: JTAG scan chain interrogation failed: all ones
Which I have been Googling, and which could mean a bad board or still another configuration issue. There is no SD card in the SD card socket and no other SPI devices on the board, although the ESP32-WROVER-32U has SPI flash on it.
Here is the complete output from openocd-esp32:
Jims-MacBook-Pro-486:~ jim$ openocd -f interface/jlink.cfg -f board/esp-wroom-32.cfg -c "program_esp32 build/hello-world.bin 0x10000 verify exit"
Open On-Chip Debugger v0.10.0-esp32-20200420 (2020-04-20-16:15)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
adapter speed: 3000 kHz
WARNING: boards/esp-wroom-32.cfg is deprecated, and may be removed in a future release.
Info : Configured 2 cores
Info : J-Link V11 compiled Apr 23 2020 16:49:23
Info : Hardware version: 11.00
Info : VTarget = 0.000 V
Info : clock speed 3000 kHz
Error: JTAG scan chain interrogation failed: all ones
Error: Check JTAG interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway...
Error: esp32.cpu0: IR capture error; saw 0x1f not 0x01
Warn : Bypassing JTAG setup events due to errors
Info : Listening on port 3333 for gdb connections
Error: JTAG scan chain interrogation failed: all ones
Error: Check JTAG interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway...
Error: esp32.cpu0: IR capture error; saw 0x1f not 0x01
Warn : Bypassing JTAG setup events due to errors
Info : cpu0: Debug controller 0 was reset.
Info : cpu0: Core 0 was reset.
Error: esp32_soc_reset: Couldn't halt target before SoC reset
embedded:startup.tcl:449: Error: ** Unable to reset target **
in procedure 'program_esp32'
in procedure 'program_esp' called at file "/Users/jim/.espressif/tools/openocd-esp32/v0.10.0-esp32-20200420/openocd-esp32/share/openocd/scripts/target/esp32.cfg", line 64
in procedure 'program_error' called at file "/Users/jim/.espressif/tools/openocd-esp32/v0.10.0-esp32-20200420/openocd-esp32/share/openocd/scripts/target/esp_common.cfg", line 75
at file "embedded:startup.tcl", line 449
Warn : Flash driver of esp32.flash does not support free_driver_priv()
Warn : Flash driver of esp32.irom does not support free_driver_priv()
Warn : Flash driver of esp32.drom does not support free_driver_priv()
Success! This circuit used the Segger 10 pin needle connector. On that connector pin 1 is VTREF and on my board it was left floating, when it should have been connected to V3.3. I connected it and:
Jims-MacBook-Pro-486:~ jim$ openocd -f interface/jlink.cfg -f board/esp32-wrover.cfg
Open On-Chip Debugger v0.10.0-esp32-20200420 (2020-04-20-16:15)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
adapter speed: 1000 kHz
WARNING: boards/esp32-wrover.cfg is deprecated, and may be removed in a future release.
If your board is ESP32-WROVER-KIT, use board/esp32-wrover-kit-1.8v.cfg instead.
Info : Configured 2 cores
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : J-Link V11 compiled Apr 23 2020 16:49:23
Info : Hardware version: 11.00
Info : VTarget = 3.290 V
Info : clock speed 1000 kHz
Info : JTAG tap: esp32.cpu0 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
Info : JTAG tap: esp32.cpu1 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
Info : esp32: Debug controller 0 was reset.
Info : esp32: Core 0 was reset.
Info : esp32: Debug controller 1 was reset.
Info : esp32: Core 1 was reset.
Info : Listening on port 3333 for gdb connections
I would suggest to validate your setup step by step - I personally do not like big bang integrations.
Verify that your the Segger software can see your JLink probe - the good thing is that lsusb can see it. JLink Commander should provide some useful information.
Launch openocd without any executable-related arguments: openocd -f interface/jlink.cfg -f board/esp-wroom-32.cfg
Verify that basic commands are working, i.e. resetting the CPU, displaying registers, reading/writing memory.
If you you are still experimenting issues, double-check your wiring - see here for more information.

NetGear N150 wireless usb stick not working with Raspbian Wheezy on my PI

I am running a RaspberryPi with raspbian-wheezy:
uname -a
Linux raspberrypi 3.18.5+ #744 PREEMPT Fri Jan 30 18:19:07 GMT 2015 armv6l GNU/Linux
How i want to use a NetGear N150 Wireless USB stick as a wlan interface:
dmesg
[ 3.401856] usb 1-1.2: new high-speed USB device number 4 using dwc_otg
[ 3.523552] usb 1-1.2: New USB device found, idVendor=0846, idProduct=9043
[ 3.532493] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 3.541771] usb 1-1.2: Product: WNA1000Mv2
[ 3.547744] usb 1-1.2: Manufacturer: Realtek
[ 3.553858] usb 1-1.2: SerialNumber: 00e04c000001
The device is not automatically detected. After plugging in the stick into a windows machine, it seems as the stick uses a Realtek rtl8192cu chip. Loading the 8192cu kernel module does not seem to work, there is still no wlan0 device.
Any ideas?
Never mind, I found a solution:
The usb id is not detected by the 8192cu kernel module as a supported device. After tweaking a bit and adding the following code to the rc.local file, everything works as expected:
modprobe 8192cu
echo "0846 9043" > /sys/bus/usb/drivers/rtl8192cu/new_id
ifdown wlan0
ifup wlan0
To have this handled automatically on module insertion, put the following line in /etc/modprobe.d/netgear_n150.conf:
install 8192cu /sbin/modprobe --ignore-install 8192cu; echo "0846 9043" > /sys/bus/usb/drivers/rtl8192cu/new_id
Going the extra mile: having it load automatically is more system specific, but on Arch Linux, adding a file in /etc/modules.load.d containing the module name is sufficient.

Debugging - GNU ARM Bare Metal Development

I am trying to debug a sample code given by Atmel. I have built the program successfully.
For debugging, I am using eclipse plusgdb plus JlinkGDBServer plus onboard Jtag.
Although the program can be downloaded to the board and is running well, I can't debug the program. Everytime I launch a debug session, the JLinkGDBServer will be terminated with an error as below:
Below are the messages shown in the console for each program termination:
JLinkGDBServer
SEGGER J-Link GDB Server V4.96g Command Line Version
JLinkARM.dll V4.96g (DLL compiled Feb 6 2015 17:54:32)
-----GDB Server start settings-----
GDBInit file: none
GDB Server Listening port: 2331
SWO raw output listening port: 2332
Terminal I/O port: 2333
Accept remote connection: localhost only
Generate logfile: on
Verify download: on
Init regs on start: on
Silent mode: off
Single run mode: on
Target connection timeout: 5 ms
------J-Link related settings------
J-Link Host interface: USB
J-Link script: none
J-Link settings file: none
------Target related settings------
Target device: Cortex-A5
Target interface: JTAG
Target interface speed: 1000kHz
Target endian: little
Connecting to J-Link...
J-Link is connected.
Firmware: J-Link OB-SAM3U128 V1 compiled Nov 28 2014 10:24:11
Hardware: V1.00
S/N: 480300770
Checking target voltage...
Target voltage: 3.30 V
Listening on TCP/IP port 2331
Connecting to target...
J-Link found 1 JTAG device, Total IRLen = 4
JTAG ID: 0x4BA00477 (Cortex-A5)
Connected to target
Waiting for GDB connection...Connected to 127.0.0.1
Reading all registers
Read 4 bytes # address 0x00000000 (Data = 0xE59FF070)
Target interface speed set to 1000 kHz
Resetting target
Halting target CPU...
...Target halted (PC = 0x00000000)
PC = 00000000, CPSR = 000001D3 (SVC mode, ARM FIQ dis. IRQ dis.)
R0 = 00000004, R1 = 0031E0C3, R2 = 00016AAD, R3 = 00016965
R4 = 0031FFA0, R5 = C0542A08, R6 = C0512000, R7 = C051DA90
USR: R8 =C051DD80, R9 =410FC051, R10=C0512000, R11 =0031FF94, R12 =003020C0
R13=BEBF5C70, R14=B6F12F1C
FIQ: R8 =9ABE0586, R9 =7E72A55E, R10=73DBFC6B, R11 =4F6717CF, R12 =05EDA809
R13=5AC81462, R14=24683958, SPSR=370D2C67
SVC: R13=0031FF80, R14=00300620, SPSR=000001D3
ABT: R13=C0542B4C, R14=C000DC80, SPSR=A0000193
IRQ: R13=00320000, R14=80000053, SPSR=80000053
UND: R13=C0542B58, R14=C000DB60, SPSR=60000093
Reading all registers
Select auto target interface speed (1000 kHz)
Flash breakpoints enabled
Semi-hosting enabled (VectorAddr = 0x08)
Semihosting I/O set to TELNET and GDB Client
Downloading 15488 bytes # address 0x00300000 - Verified OK
Writing register (PC = 0x00300080)
GDB closed TCP/IP connection
Connected to 127.0.0.1
Reading all registers
Read 4 bytes # address 0x00300080 (Data = 0xF1080100)
Resetting target
Writing register (PC = 0x00300000)
Writing register (PC = 0x00300000)
Starting target CPU...
GDB closed TCP/IP connection
arm-none-eabi-gdb
Warning: the current language does not match this frame.
The target endianness is set automatically (currently little endian)
Semihosting and SWV
SEGGER J-Link GDB Server V4.96g - Terminal output channel
Connection closed by the GDB server.
The following is my debugging configuration:
Under the Run Commands, the commands in the box are as below:
target remote localhost:2331
monitor reset
load
mon reg pc = 0x300000
mon reg pc = 0x300000
end
I dont know what root cause is. I suspect that it is arm-none-eabi-gdb that causes the JLinkGDBServer to terminate with an exit code of -1.
Please help.
Edit 1
FYI, I am using SAMA5D3x-EK development board.
It is difficult to say, but looks like if the processor is having an exception while loading your code. I suggest to verify the load address of the sections of your ELF file, and review the linker settings of your project.
Hope it helps...