Error: Halt timed out, wake up GDB - gdb

I'm having trouble using OpenOCD to flash the firmware on a at91sam7s512 micro-controller.
Whenever I send a halt command (via telnet) it throws the following error:
Halt timed out, wake up GDB.
timed out while waiting for target halted
in procedure 'halt'
The board is a Proxmark3 Easy
Below is the configuration file being used:
# Ports
telnet_port 4444
gdb_port 3333
# Interface
interface buspirate
buspirate_port /dev/ttyUSB0
adapter_khz 1000
# Communication speed
buspirate_speed normal # or fast
# Voltage regulator: enabled = 1 or disabled = 0
buspirate_vreg 1
# Pin mode: normal or open-drain
buspirate_mode normal
# Pull-up state: enabled = 1 or disabled = 0
buspirate_pullup 1
# use combined on interfaces or targets that can't set TRST/SRST separately
reset_config srst_only srst_pulls_trst
jtag newtap sam7x cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id 0x3f0f0f0f
target create sam7x.cpu arm7tdmi -endian little -chain-position sam7x.cpu
sam7x.cpu configure -event reset-init {
soft_reset_halt
mww 0xfffffd00 0xa5000004 # RSTC_CR: Reset peripherals
mww 0xfffffd44 0x00008000 # WDT_MR: disable watchdog
mww 0xfffffd08 0xa5000001 # RSTC_MR enable user reset
mww 0xfffffc20 0x00005001 # CKGR_MOR : enable the main oscillator
sleep 10
mww 0xfffffc2c 0x000b1c02 # CKGR_PLLR: 16MHz * 12/2 = 96MHz
sleep 10
mww 0xfffffc30 0x00000007 # PMC_MCKR : MCK = PLL / 2 = 48 MHz
sleep 10
mww 0xffffff60 0x00480100 # MC_FMR: flash mode (FWS=1,FMCN=72)
sleep 100
}
gdb_memory_map enable
#gdb_breakpoint_override hard
#armv4_5 core_state arm
sam7x.cpu configure -work-area-virt 0 -work-area-phys 0x00200000 -work-area-size 0x10000 -work-area-backup 0
flash bank sam7x512.flash.0 at91sam7 0 0 0 0 sam7x.cpu 0 0 0 0 0 0 0 18432
flash bank sam7x512.flash.1 at91sam7 0 0 0 0 sam7x.cpu 1 0 0 0 0 0 0 18432
What steps can be taken to troubleshoot this

Two alternatives are open to you, JTAG and USB.
JTAG
The JTAG interface is disabled by default on some CPUs and needs to be manually enabled due to their Code Readout Protection (CRP).
To do this, you need to erase the chip by shorting PIN 55 (ERASE) with the 3.3V while the device is on.
After this the memory will be erased and protections off. You can then flash as normal.
Sources
Proxmark Forum
http://www.proxmark.org/forum/viewtopic.php?id=6306
Official CPU Documentation, section 4.9.3
http://www.equinox-tech.com/downloads/equinox/ApplicationNotes/AN122%20Atmel%20AT91SAM7%20ISP%20Programming_V1-13_250110.pdf
USB
Alternatively, you could try the process over USB instead.
First check if the Proxmark is detected when plugged in.
Run the watch command to see if any changes occur when you plug it in.
watch ls -l /dev/ttyACM0
Hold the button on the side of the Proxmark down THEN connect via USB and check if the command output for watch changes. If it did and the file becomes present, you can go ahead with this.
Be sure to leave the button pressed until the flashing process is complete.
You are required to have compiled the Proxmark3 source found at official repo https://github.com/Proxmark/proxmark3 to get both the tool for flashing (flasher) and the flash images (bootrom.elf and fullimage.elf). If you have already continue with Flashing, if not do Compilation steps below first.
Flashing
Do NOT press Enter during the flashing process
./client/flasher /dev/ttyACM0 -b bootrom/obj/bootrom.elf armsrc/obj/fullimage.elf
Start the Proxmark Client and test if works
./client/proxmark3 /dev/ttyACM0
Compilation
Add current user to dialout group
sudo adduser $USER dialout
Log out and log back in for changes to take effect
Install necessary components
sudo apt-get install p7zip git build-essential libreadline5 libreadline-dev libusb-0.1-4 libusb-dev libqt4-dev perl pkg-config wget libncurses5-dev gcc-arm-none-eabi libstdc++-arm-none-eabi-newlib
Clone repo
git clone https://github.com/proxmark/proxmark3.git
cd proxmark3
Add Udev rules
sudo cp -rf driver/77-mm-usb-device-blacklist.rules /etc/udev/rules.d/77-mm-usb-device-blacklist.rules
sudo udevadm control --reload-rules
Make
make clean && make all
Identify Proxmark3 on tty interface (usually this is ttyACM0 and this is what I'll use in Flashing)
dmesg | grep -i usb
Continue to Flashing steps
Source https://wiki.elvis.science/index.php?title=Proxmark3:_Debricking (Linux Installation)

Swap the MISO and MOSI lines. For my Bus Pirate v3 and Proxmark3 Easy the correct connections were:
TMS <-> CS
TDI <-> MOSI
TDO <-> MISO
TCK <-> CLK
GND <-> GND
+3.3 <-> +3.3

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.

Virtualbox: cannot start or recover saved machine

I'm running Virtualbox 5.1.14 r112924 on a Windows 7 Professional machine. I have installed a Debian Testing guest. Several days ago I tried to save the machine, unfortunately I do not recall the exact circumstances, but I think it had to do with the guest having no network any more after the host came back from suspend-to-RAM.
Anyway, I now have a saved machine with which I cannot do anything: I cannot start it, I cannot delete the saved state, I cannnot clone it and I cannot even delete the entire machine. All these options are greyed out in the VB Manager window. Also, I don't get any errors, so I'm rather clueless what to do.
I include below parts of the most recent log file which I thought are relevant, I didn't want to paste the whole thing.
What sort of witchcraft can bring my machine back to life?
Many thanks, and best regards,
Enno
02:37:32.316550 Changing the VM state from 'RUNNING' to 'SUSPENDING'
02:37:32.319680 AIOMgr: Endpoint for file 'D:\Users\EnnoMiddelberg\VirtualBox VMs\Debian_Testing\Debian_Testing.vdi' (flags 000c0781) created successfully
02:38:32.373466 PDMR3Suspend: 60 056 883 803 ns run time
02:38:32.373494 Changing the VM state from 'SUSPENDING' to 'SUSPENDED'
02:38:32.373520 Console: Machine state changed to 'Paused'
02:38:32.373700 VMR3Suspend:
02:38:32.393131 RUNNING -> SUSPENDING, RUNNING_LS -> SUSPENDING_EXT_LS failed, because the VM state is actually SUSPENDED
02:38:32.393177 VMSetError: F:\tinderbox\win-5.1\src\VBox\VMM\VMMR3\VM.cpp(3619) int __cdecl vmR3TrySetState(struct VM *,const char *,unsigned int,...); rc=VERR_VM_INVALID_VM_STATE
02:38:32.452926 VMSetError: VMR3Suspend failed because the current VM state, SUSPENDED, was not found in the state transition table (old state RUNNING_LS)
02:38:32.501235 ERROR [COM]: aRC=VBOX_E_VM_ERROR (0x80bb0003) aIID={872da645-4a9b-1727-bee2-5585105b9eed} aComponent={ConsoleWrap} aText={Could not suspend the machine execution (VERR_VM_INVALID_VM_STATE)}, preserve=false aResultDetail=0
02:38:32.605107 Console: Machine state changed to 'Saving'
02:38:32.635604 Changing the VM state from 'SUSPENDED' to 'SAVING'
02:38:32.747945 VUSB: Detached 'HidMouse' from port 1
02:38:40.213749 SSM: Footer at 0x23d179e4 (600930788), 34 directory entries.
02:38:40.213777 VUSB: Attached 'HidMouse' to port 1
02:38:40.231560 SSM: Successfully saved the VM state to 'D:\Users\EnnoMiddelberg\VirtualBox VMs\Debian_Testing\Snapshots\2017-05-23T14-48-18-411341300Z.sav'
02:38:40.231578 Changing the VM state from 'SAVING' to 'SUSPENDED'
02:38:40.316839 Console::powerDown(): A request to power off the VM has been issued (mMachineState=Saving, InUninit=0)
02:38:40.342613 Display::handleDisplayResize: uScreenId=0 pvVRAM=000000000c0a0000 w=1920 h=1106 bpp=32 cbLine=0x1E00 flags=0x1
02:38:40.342664 GUI: UIFrameBufferPrivate::NotifyChange: Screen=0, Origin=0x0, Size=1920x1106, Sending to async-handler
02:38:40.350656 Changing the VM state from 'SUSPENDED' to 'POWERING_OFF'
02:38:40.356473 ****************** Guest state at power off for VCpu 0 ******************
...
...
...
02:38:40.406031 ************** End of Guest state at power off ***************
02:38:41.753488 PDMR3PowerOff: Driver 'AUDIO'/0 on LUN#0 of device 'ichac97'/0 took 1 344 979 632 ns to power off
02:38:41.753791 PDMR3PowerOff: 1 347 726 353 ns run time
02:38:41.762544 Changing the VM state from 'POWERING_OFF' to 'OFF'
02:38:41.983956 Changing the VM state from 'OFF' to 'DESTROYING'
02:38:41.984097 ************************* Statistics *************************
...
...
...
02:38:41.990221 ********************* End of statistics **********************
02:38:41.997747 VUSB: Detached 'HidMouse' from port 1
02:38:42.377555 NAT: Zone(nm:mbuf_cluster, used:90)
02:38:42.378711 NAT: Zone(nm:mbuf_packet, used:90)
02:38:42.378737 NAT: Zone(nm:mbuf, used:90)
02:38:42.378763 NAT: Zone(nm:mbuf_jumbo_pagesize, used:0)
02:38:42.379768 NAT: Zone(nm:mbuf_jumbo_9k, used:0)
02:38:42.380260 NAT: Zone(nm:mbuf_jumbo_16k, used:0)
02:38:42.380639 NAT: Zone(nm:mbuf_ext_refcnt, used:0)
02:39:42.706185 GIM: KVM: Resetting MSRs
02:39:42.720224 Changing the VM state from 'DESTROYING' to 'TERMINATED'
02:39:42.723143 Console: Machine state changed to 'Saved'
02:39:42.723504 GUI: Request to close Runtime UI because VM is powered off already.
02:39:42.888614 GUI: Passing request to close Runtime UI from machine-logic to UI session.
Ok, so I got the machine back up by removing the *.sav file in the guest's "Snapshots" subdirectory. It had to sort out its file system when booting, but everything is running as it should now.
Thanks for listening, anyway...

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

Ember CLI build killed

I build my Ember CLI app inside a docker container on startup. The build fails without an error message, it just says killed:
root#fstaging:/frontend/source# node_modules/ember-cli/bin/ember build -prod
version: 1.13.15
Could not find watchman, falling back to NodeWatcher for file system events.
Visit http://www.ember-cli.com/user-guide/#watchman for more info.
Buildingember-auto-register-helpers is not required for Ember 2.0.0 and later please remove from your `package.json`.
Building.DEPRECATION: The `bind-attr` helper ('app/templates/components/file-selector.hbs' # L1:C7) is deprecated in favor of HTMLBars-style bound attributes.
at isBindAttrModifier (/app/source/bower_components/ember/ember-template-compiler.js:11751:34)
Killed
The same docker image successfully starts up in another environment, but without hardware constraints. Does Ember CLI have hard-coded hardware constraints for the build process? The RAM is limited to 128m and swap to 2g.
That is likely not enough memory for Ember CLI to do what it needs. You are correct in that, the process is being killed because of an OOM situation. If you log in to the host and take a look at the dmesg output you will probably see something like:
V8 WorkerThread invoked oom-killer: gfp_mask=0xd0, order=0, oom_score_adj=0
V8 WorkerThread cpuset=867781e35d8a0a231ef60a272ae5d418796c45e92b5aa0233df317ce659b0032 mems_allowed=0
CPU: 0 PID: 2027 Comm: V8 WorkerThread Tainted: G O 4.1.13-boot2docker #1
Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
0000000000000000 00000000000000d0 ffffffff8154e053 ffff880039381000
ffffffff8154d3f7 ffff8800395db528 ffff8800392b4528 ffff88003e214580
ffff8800392b4000 ffff88003e217080 ffffffff81087faf ffff88003e217080
Call Trace:
[<ffffffff8154e053>] ? dump_stack+0x40/0x50
[<ffffffff8154d3f7>] ? dump_header.isra.10+0x8c/0x1f4
[<ffffffff81087faf>] ? finish_task_switch+0x4c/0xda
[<ffffffff810f46b1>] ? oom_kill_process+0x99/0x31c
[<ffffffff811340e6>] ? task_in_mem_cgroup+0x5d/0x6a
[<ffffffff81132ac5>] ? mem_cgroup_iter+0x1c/0x1b2
[<ffffffff81134984>] ? mem_cgroup_oom_synchronize+0x441/0x45a
[<ffffffff8113402f>] ? mem_cgroup_is_descendant+0x1d/0x1d
[<ffffffff810f4d77>] ? pagefault_out_of_memory+0x17/0x91
[<ffffffff815565d8>] ? page_fault+0x28/0x30
Task in /docker/867781e35d8a0a231ef60a272ae5d418796c45e92b5aa0233df317ce659b0032 killed as a result of limit of /docker/867781e35d8a0a231ef60a272ae5d418796c45e92b5aa0233df317ce659b0032
memory: usage 131072kB, limit 131072kB, failcnt 2284203
memory+swap: usage 262032kB, limit 262144kB, failcnt 970540
kmem: usage 0kB, limit 9007199254740988kB, failcnt 0
Memory cgroup stats for /docker/867781e35d8a0a231ef60a272ae5d418796c45e92b5aa0233df317ce659b0032: cache:340KB rss:130732KB rss_huge:10240KB mapped_file:8KB writeback:0KB swap:130960KB inactive_anon:72912KB active_anon:57880KB inactive_file:112KB active_file:40KB unevictable:0KB
[ pid ] uid tgid total_vm rss nr_ptes nr_pmds swapents oom_score_adj name
[ 1993] 0 1993 380 1 6 3 17 0 sh
[ 2025] 0 2025 203490 32546 221 140 32713 0 npm
Memory cgroup out of memory: Kill process 2025 (npm) score 1001 or sacrifice child
Killed process 2025 (npm) total-vm:813960kB, anon-rss:130184kB, file-rss:0kB
It might be worthwhile to profile the container using something like https://github.com/google/cadvisor to find out what kind of memory maximums it may need.

Debugging and killing apps on Mac OS X?

Hey all, I'm in the process of debugging a C++ app on mac os 10.5. Occasionally, I'll do something bad and cause a segfault or an otherwise illegal operation. This results in the app hanging for a while, and eventually a system dialog notifying me of the crash. The wait time between the "hang" and the dialog is significant; a few minutes. If I try to force quit the application or kill -9 it from the command line nothing happens. If I start the app from the debugger (gdb), upon a crash I get back to gdb prompt and can exit the process cleanly. That's not ideal though as gdb is slow to load.
Anyway, can you guys recommend something? Is there a way to disable the crash reporting mechanism in OS X?
Thanks.
Update 1:
Here're the zombies that are left over from an XCode execution. Apparently xcode can't stop 'em properly either.
1 eightieight#eightieights-MacBook-Pro:~$ ps auxw|grep -i Reader
2 eightieight 28639 0.0 0.0 599828 504 s004 R+ 2:54pm 0:00.00 grep -i reader
3 eightieight 28288 0.0 1.1 1049324 45032 ?? UEs 2:46pm 0:00.89 /Users/eightieight/workspace/spark/spark/reader/browser/build/Debug/Reader.app/Contents/MacOS/Reader
4 eightieight 28271 0.0 1.1 1049324 45036 ?? UEs 2:45pm 0:00.89 /Users/eightieight/workspace/spark/spark/reader/browser/build/Debug/Reader.app/Contents/MacOS/Reader
5 eightieight 28146 0.0 1.1 1049324 44996 ?? UEs 2:39pm 0:00.90 /Users/eightieight/workspace/spark/spark/reader/browser/build/Debug/Reader.app/Contents/MacOS/Reader
6 eightieight 27421 0.0 1.1 1049328 45024 ?? UEs 2:29pm 0:00.88 /Users/eightieight/workspace/spark/spark/reader/browser/build/Debug/Reader.app/Contents/MacOS/Reader
7 eightieight 27398 0.0 1.1 1049324 45044 ?? UEs 2:28pm 0:00.90 /Users/eightieight/workspace/spark/spark/reader/browser/build/Debug/Reader.app/Contents/MacOS/Reader
There's the CrashReporterPrefs app that comes with XCode (search for it with Spotlight; should be in /Developer/Applications/Utilities). That can be to set to Server Mode to disable the application 'Unexpectedly Quit' dialog too.
Here's another suggestion:
sudo chmod 000 /System/Library/CoreServices/Problem\ Reporter.app
To re-enable, do the following:
sudo chmod 755 /System/Library/CoreServices/Problem\ Reporter.app
It might be that the application is dumping a large core file - you'd probably notice the effect on available disk space though. You can switch off core dumping using
sudo sysctl -w kern.coredump=0
Reactivate by setting =1.
This article from osxdaily.com says you just need to type:
defaults write com.apple.CrashReporter DialogType none
in the terminal. Don't know if that will fix the delay though.
I finally figured it out.
in /System/Library/CoreServices:
---------- 1 root wheel 56752 11 Aug 2009 ReportPanic
That must've been from my earlier attempts to disable the annoying report dialog. Live and learn. :]