ocd assertion fault when connecting gdb - openocd

I am debugging board STM32f4 Discovery on Ubuntu 20.04 with openocd and arm-none-eabi-none. Things work well until yesterday. Today, when I connect the gdb to localhost:4444, following assertion happened and ocd quit:
Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 2000 kHz
adapter_nsrst_delay: 100
none separate
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Started by GNU MCU Eclipse
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : clock speed 1800 kHz
Info : STLINK v2 JTAG v37 API v2 SWIM v26 VID 0x0483 PID 0x374B
Info : using stlink api v2
Info : Target voltage: 2.894743
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'gdb' connection on tcp/3333
Info : device id = 0x100f6413
Info : flash size = 8194kbytes
openocd: src/flash/nor/stm32f2x.c:990: stm32x_probe: Assertion `(bank->size >> 10) == flash_size_in_kb' failed.
I see that it is using stm32f2x.c, is it correct since the chip is stm32f407vgt?

I found the issue: I scale up the clock speed without switching to appropriate Flash Latency so the debugger will lose the track of program address as mentioned here, in Clocks and initial settings part:
https://vjordan.info/log/fpga/first-steps-with-the-stm32f4.html

Related

STM32cubeide with stm32f103c8t6 could not verify ST device

I am new to embedded and stm32cubeide, self teaching so I can use it in a group project related to university studies.
After purchasing a "blue pill" from aliexpress, I realized I might of bought a clone chip. I followed the instructions shown here (stm32 community site), and I'm still getting an error that the ide cannot verify my ST device.
Here is what I have as output:
Open On-Chip Debugger 0.11.0+dev-00443-gcf12591 (2022-02-09-13:33) [ST Internal]
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
swv
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : STLINK V2J39S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.286227
Info : clock speed 4000 kHz
Info : stlink_dap_op_connect(connect)
Info : SWD DPIDR 0x2ba01477
Info : STM32F103C8Tx.cpu: Cortex-M3 r2p1 processor detected
Info : STM32F103C8Tx.cpu: target has 6 breakpoints, 4 watchpoints
Info : starting gdb server for STM32F103C8Tx.cpu on 3333
Info : Listening on port 3333 for gdb connections
Info : accepting 'gdb' connection on tcp/3333
Info : device id = 0x20036410
Info : flash size = 128kbytes
Warn : GDB connection 1 on target STM32F103C8Tx.cpu not halted
undefined debug reason 8 - target needs reset
O.K.
O.K.:0xE00FFFD0
Info : dropped 'gdb' connection
shutdown command invoked
I see in the console "undefined debug reason 8 - target needs reset", is this the problem? If so what can I do to solve this? If not, then what do I do other than purchasing another board?
Below is my test Debug.cfg, in case I need to change something in there:
# This is an genericBoard board with a single STM32F103C8Tx chip
#
# Generated by STM32CubeIDE
# Take care that such file, as generated, may be overridden without any early notice. Please have a look to debug launch configuration setup(s)
source [find interface/stlink-dap.cfg]
set WORKAREASIZE 0x5000
transport select "dapdirect_swd"
set CHIPNAME STM32F103C8Tx
set BOARDNAME genericBoard
# Enable debug when in low power modes
set ENABLE_LOW_POWER 1
# Stop Watchdog counters when halt
set STOP_WATCHDOG 1
# STlink Debug clock frequency
set CLOCK_FREQ 4000
# Reset configuration
# use software system reset if reset done
reset_config none
set CONNECT_UNDER_RESET 0
set CORE_RESET 0
# ACCESS PORT NUMBER
set AP_NUM 0
# GDB PORT
set GDB_PORT 3333
# BCTM CPU variables
source [find target/stm32f1x.cfg]
# SWV trace
set USE_SWO 0
set swv_cmd "-protocol uart -output :3344 -traceclk 16000000"
source [find board/swv.tcl]
Thanks
I found some FT232 that I had in spare, and I was able to program the chip using the stm32 programmer software and a generated hex file from the ide.
I'll use this method if ever I run into cloned chips and the st link v2 if ever I get a genuine board.

Failed isochronous start. Error: 0x2 ;When starting reading from 2 cameras PTGrey

I have a PTGrey FL3-U3-13E4C-C USB 3 camera. I am able to read and store images for a single camera from the default code provided by PTGrey.
But when I try to run the MultipleCameraEx for testing with 2 Cameras connected, I get the Failed isochronous start Error.
I tried manually setting the number of cameras to 2 and running the code without the for loop, I still get the same error for 2 Cameras.
I get the following error.
FlyCapture2 library version: 2.10.3.266
Application build date: Apr 8 2017 17:45:42
Number of cameras detected: 2
* CAMERA INFORMATION *
Serial number - 16362359
Camera model - Flea3 FL3-U3-13E4C
Camera vendor - Point Grey Research
Sensor - E2v EV76C560 (1/1.8" Color CMOS)
Resolution - 1280x1024
Firmware version - 2.15.3.3
Firmware build time - Wed Jul 29 16:41:55 2015
* CAMERA INFORMATION *
Serial number - 16362353
Camera model - Flea3 FL3-U3-13E4C
Camera vendor - Point Grey Research
Sensor - E2v EV76C560 (1/1.8" Color CMOS)
Resolution - 1280x1024
Firmware version - 2.15.3.3
Firmware build time - Wed Jul 29 16:41:55 2015
Error Trace:
Source: IidcCameraInternal.cpp(469) Built: Oct 20 2016 20:17:21 - Error starting isochronous stream.
+-> From: Iso.cpp(2046) Built: Oct 20 2016 20:16:34 - Failed isochronous start. Error: 0x2.
If your developing under Linux, your issue might be connected to the maximum available amount of memory allocated to the USB subsystem, being too small (that was the cause of my issue!).
To use multiple cameras the usbcore variable usbfs_memory_mb should be set suitably large (e.g. 1024). In my case, even with just one single Point Grey Blackfly BFLY-U3-23S6C camera, the default buffer allocated (16 on my machine running Ubuntu 16.04 LTS) was too small.
To do that use
$ sudo modprobe usbcore usbfs_memory_mb=1024
OR
$ sudo sh -c 'echo 1024 > /sys/module/usbcore/parameters/usbfs_memory_mb'
The change will be valid until the next restart.
To make the change permanent add options usbcore usbfs_memory_mb=1024 to an appropriate /etc/modprobe.d file (e.g. /etc/modprobe.d/usbcore.conf).
To check what is the current setting of usbfs_memory_mb use
$ sudo cat /sys/module/usbcore/parameters/usbfs_memory_mb

Profiling OpenCV using OProfile

I have this basic OpenCV program:
#include <iostream>
#include "opencv2/opencv.hpp"
int main(){
std::cout<<"Reading Image..."<<std::endl;
cv::Mat img = cv::imread("all_souls_000000.jpg", cv::IMREAD_GRAYSCALE);
if(!img.data)
std::cerr<<"Error reading image"<<std::endl;
return 0;
}
Which creates the executable ReadImage. I want to profile it using OProfile. However, running:
operf ./ReadImage > ReadImage.log
Returns:
Kernel profiling is not possible with current system config.
Set /proc/sys/kernel/kptr_restrict to 0 to collect kernel samples.
operf: Profiler started
* * * * WARNING: Profiling rate was throttled back by the kernel * * * *
The number of samples actually recorded is less than expected, but is
probably still statistically valid. Decreasing the sampling rate is the
best option if you want to avoid throttling.
Profiling done.
Why this happens? What is the best way to profile OpenCV?
I was able to run operf on an opencv app, with this result, is this what you are looking for?
Profiling started at Tue Jan 31 16:52:48 2017
Profiling stopped at Tue Jan 31 16:52:53 2017
-- OProfile/operf Statistics --
Nr. non-backtrace samples: 337018
Nr. kernel samples: 5603
Nr. user space samples: 331415
Nr. samples lost due to sample address not in expected range for domain: 0
Nr. lost kernel samples: 0
Nr. samples lost due to sample file open failure: 0
Nr. samples lost due to no permanent mapping: 0
Nr. user context kernel samples lost due to no app info available: 0
Nr. user samples lost due to no app info available: 0
Nr. backtraces skipped due to no file mapping: 0
Nr. hypervisor samples dropped due to address out-of-range: 0
Nr. samples lost reported by perf_events kernel: 0

OpenOCD on Beaglebone Black

This is my first post ever on this board and I am also fairly new to the world of JTAG debugging, I have used a few commercial products before but I would like to make the switch to OpenOCD and I am experiencing a lot of failures so far. I have tried to attach to my Beaglebone Black using a Flyswatter2 and the kit that they provide and most of my results look something like this:
$ ./openocd -f interface/ftdi/flyswatter2.cfg -f
board/ti_beaglebone_with_fs2.cfg -c init -c "reset init"
Open On-Chip Debugger 0.10.0-dev-00149-g8229d52 (2015-12-23-11:37)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Warn : Interface already configured, ignoring
adapter speed: 16000 kHz
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
Warn : target name is deprecated use: 'cortex_a'
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain
connect_deassert_srst
Info : clock speed 16000 kHz
Info : JTAG tap: am335x.jrc tap/device found: 0x2b94402f (mfg: 0x017,
part: 0xb944, ver: 0x2)
Info : JTAG tap: am335x.dap enabled
Warn : Timeout (1000ms) waiting for ACK=OK/FAULT in JTAG-DP transaction
- aborting
Info : JTAG tap: am335x.jrc tap/device found: 0x2b94402f (mfg: 0x017,
part: 0xb944, ver: 0x2)
Info : JTAG tap: am335x.dap enabled
Error: JTAG-DP OVERRUN - check clock, memaccess, or reduce jtag speed
Error: MEM_AP_CSW 0x2800060, MEM_AP_TAR 0x0
Error: JTAG-DP OVERRUN - check clock, memaccess, or reduce jtag speed
Error: MEM_AP_CSW 0x2800060, MEM_AP_TAR 0x0
Error: JTAG-DP OVERRUN - check clock, memaccess, or reduce jtag speed
Error: MEM_AP_CSW 0x2800060, MEM_AP_TAR 0x0
Error: JTAG-DP OVERRUN - check clock, memaccess, or reduce jtag speed
Error: MEM_AP_CSW 0x2800060, MEM_AP_TAR 0x0
Error: JTAG-DP OVERRUN - check clock, memaccess, or reduce jtag speed
Error: MEM_AP_CSW 0x2800060, MEM_AP_TAR 0x0
Error: JTAG-DP OVERRUN - check clock, memaccess, or reduce jtag speed
Error: MEM_AP_CSW 0x2800060, MEM_AP_TAR 0x0
Error: JTAG-DP OVERRUN - check clock, memaccess, or reduce jtag speed
Error: MEM_AP_CSW 0x2800060, MEM_AP_TAR 0x0
Error: JTAG-DP OVERRUN - check clock, memaccess, or reduce jtag speed
Error: MEM_AP_CSW 0x2800060, MEM_AP_TAR 0x0
Error: JTAG-DP OVERRUN - check clock, memaccess, or reduce jtag speed
Error: MEM_AP_CSW 0x2800060, MEM_AP_TAR 0x0
Error: JTAG-DP OVERRUN - check clock, memaccess, or reduce jtag speed
Error: MEM_AP_CSW 0x2800060, MEM_AP_TAR 0x0
Error: Target not examined yet
in procedure 'reset'
in procedure 'ocd_bouncer'
I have tried to reduce the adapter speed with some success, where the device actually reboots but all hell breaks loose once the kernel starts at which point I get error messages similar to the ones above.
I am not really sure where to start as those error messages are still a little obscure to me, would anyone have any ideas/thoughts/suggestions? I'd be willing to dig in the source and make some adjustments if need be, but right now I'm a little bit too clueless to do so!
Well, just since I can't seem to find any other post that shows ppl succesfully debugging the BeableBone Black with openocd, I can vouch for the fact that it works. My commandline (using the TIAO):
sudo ../src/openocd -f interface/ftdi/tumpa.cfg -f board/mybbb.cfg
Note that the paths come from the fact that I built it and ran it from source (you might need other path prefixes). The mybbb.cfg is basically the one from flyswatter, except the interface line. (https://www.tincantools.com/w/images/f/f7/ti_beaglebone_with_fs2.cfg)
Openocd can be a bit hard to use, but it does forces you to understand what really is happening with the JTAG. If you won't want to, just buy the 80$ connector from TI, and it will -just- work (provided that you get the pinheader soldered on it correctly)
FYI: The succesful output in my case (useful to diff):
testbox#testbox-VirtualBox:~/openocd/openocd-code/tcl$ sudo ../src/openocd -f interface/ftdi/tumpa.cfg -f board/ti_beaglebone.cfg
Open On-Chip Debugger 0.10.0-dev-00322-g406f4d1 (2016-06-09-09:22)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
none separate
adapter speed: 16000 kHz
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
trst_and_srst separate srst_gates_jtag trst_push_pull srst_push_pull connect_deassert_srst
Info : ftdi: if you experience problems at higher adapter clocks, try the command "ftdi_tdo_sample_edge falling"
Info : clock speed 16000 kHz
Info : JTAG tap: am335x.jrc tap/device found: 0x2b94402f (mfg: 0x017 (Texas Instruments), part: 0xb944, ver: 0x2)
Info : JTAG tap: am335x.dap enabled
Info : am335x.cpu: hardware has 6 breakpoints, 2 watchpoints
Finally, regarding your errors, I would double check the solder, since openocd really is saying your clock might be too fast. Fast clocking with small leakage might explain your issue?
One last thing to note:
If you want to debug the linux kernel with JAG on the beaglebone on a recent kernel, you might need a patch. If not, you will get errors in openocd (but also with the dongles from TI) once linux boots since it messes up the JTAG. See the 1-line patch in https://e2e.ti.com/support/embedded/linux/f/354/t/363421 (took me a while to find!)
Good luck!
Be sure that your config file is providing the good ID Vendor and ID product of your target. The command lsusb give you your target IDs.

HP ProLiant 100 G5/G6/G7 Servers Series - Showing Uncorrectable ECC Events Occurred in SEL Log

HP Insight Diagnostics Version 8.4.0.3521A (x86_64)
Computer Name: ezsetupsystem3c4a927c9e88
During Device test it gives following error
Total Memory-ECC test Failed
Description- Uncorrectable ECC Events occurred in SEL log Device, Ran on CPU 0
Recommended Repair- Please refer IPMI Sensor Event Log for ECC events
Error Code- 021278
Please help me n finding why is this error coming.
Is it because of WAMP server installation??
This means that the server has a DIMM which has exceeded it's acceptable ECC error count. It's location is denoted in the error. Depending on the platform, you can identify the specific slot. Which HP ProLiant model is this? This is standard warranty repair.
You have faulty memory. To identify the faulty memory run HPS Reports:
http://update.external.hp.com/HPS/HPSreports/
Once completed you have to unzip the archive an open the index.html file insite.
It will collect all hardware information and highlight in
RED
the faulty components.