I'm using Keil to flash the software to on stm32f407 discovery.
But the software only starts working when I pullout the JLINK cable and plug it again.
Why is that?
By default uVision holds the target in RESET after flashing with the the Download (F8) function. I would argue that this is a safety feature - if your code controls some electro-mechanical system for example you might not want it to start-up spontaneously.
You can change this behaviour via Flash->Configure Flash Tools->Settings...
Alternatively if you load by running the debugger, it will start-up and by default breakpoint at main() - that default can be changed to run straight through. Any explicitly set breakpoints will cause a halt of course.
I am attempting to program a STM32VLDiscovery Board, using Visual Studio 2019, Visual GDB and STM32CubeMX. When I connect the board to the machine, it appears as 'USB Mass Storage Device'. I am using a Windows 10 VM. The program builds fine, but when I attempt to begin on-board debugging, I get an error message stating:
USB Mass Storage Device" does not appear to have "ST-Link Driver"
driver installed. The debugger may have problems finding your decvice.
Try installing it now?
If I click yes, then a bit of software called UsbDriverTool.exe starts and a progress bar appears with the message
VisualGDB is installing the following USB driver: ST-Link Driver the following device: USB Mass Storage Device
This then fails with the message
Automatic driver installation gailed. Do you want to try installing it manually?
Clicking 'yes' again gets the message
USB driver installation failed with code -532462766
And then finally
open failed (no matching adapter found)
Can anyone tell me please, how I go about getting the ST-Link driver on to the discovery board so that I can start debugging my code?
(One other thing that may be relevant. I tried using the STM32 ST-Link Utility program to program the code on to the board. I find that it will only connect to the board if I am holding reset whilst I press the 'connect' button.
I'm running pharo 5 (seaside) in headless mode, with RFB:
./pharo -vm-display-null -vm-sound-null /app/pharo5/Pharo5.0.image --no-quit
Locally works well (Ubuntu 14 with XFCE).
In DigitalOcean (Ubuntu 14 without GUI) it works until the debugger is activated: then it closes.
I can connect via VNC with no problem, but when I execute a Halt or an error it triggers the debugger, it leaves ... some clue of the problem?
This sounds like a case where remote debugging might be a reasonable approach. This project, PharmIDE, (previously name, "Remote Debugging", currently named "TelePharo") purports to provide debugging of remote images. There is a repository for it on Github under the current name.
*[Disclaimer, I have not used it.]
I seem to be having issues with integrating Xcode6 with jenkins, I currently have this setup and working with Xcode 5.
With xcode 6 running remotely via SSH the simulator time-out, when I run locally it succeeds.
Command
xcodebuild -workspace PROJECTNAME.xcworkspace -scheme BGO_Tests -destination 'platform=iOS Simulator,name=iPhone 5s' -derivedDataPath ./Build clean test
2014-08-19 10:46:36.591 xcodebuild[33966:381f] iPhoneSimulator: Timed out waiting 120 seconds for >simulator to boot, current state is 1.
Testing failed:
Test target BGO_Tests encountered an error (Timed out waiting 120 seconds for simulator to boot, current state is 1
Tested with recent Xcode 6 beta 6
Note: the device names changed in Xcode 7, so you no longer specify them using iPhone 5 (9.1 Simulator) but rather iPhone 5 (9.1).
Use xcrun instruments -s to get the current list of devices and then you can pre-launch it using:
xcrun instruments -w "iPhone 5 (9.1)" || echo "(Pre)Launched the simulator."
Prelaunching
I got to a point where what I proposed down there wasn't working anymore. In addition to making the changes mentioned here, you need to launch the simulator xcodebuild is expecting BEFORE xcodebuild is ran:
# First get the UDID you need
xcrun instruments -s
# Then launch it
open -a "iOS Simulator" --args -CurrentDeviceUDID <sim device UDID>
# and wait some time....
sleep 5
# Then launch your unit tests
xcodebuild [...] -destination 'platform=iOS Simulator,name=<device name matching the UDID>'
Old post
This bug is fixed in Xcode 6.3 and above. If you are experiencing similar problems in newer Xcode, it's likely another bug.
Apple follow up regarding Bug ID# 18001199:
The context provided by LaunchDaemons is not supported for running GUI
applications. The SSH service, and the default setup for Jenkins, are
both implemented as LaunchDaemons. In earlier versions of Xcode 5
xcodebuild could run tests on the iOS simulator in this context, but
that was never a supported configuration, and as you have noted that
is no longer working as of Xcode 6.
Unlike LaunchDaemons, LaunchAgents provide a context where you can run
GUI applications - if the user is logged in at the time, with a window
server / Aqua session. Converting your Jenkins configuration from
being a LaunchDaemon to being a LaunchAgent would avoid the reported
issue. You can also use launchd for running tests on the iOS simulator
from a SSH session, either by crafting a LaunchAgent and manually
loading / starting that, or by using "launchctl submit”.
Ok, after some more digging around the comments around here (many thanks to Opal), I found out that launching the slave via JNLP instead works.
As many people mentioned, it is not currently possible to run the unit test over SSH, so you might want to turn towards the JNLP agent for now until Apple fixes it.
If connecting with JNLP still does not solve it, try the solution mentioned in this comment.
i.e.: Run these on command line:
DevToolsSecurity -enable
sudo dscl . -append /Groups/_developer GroupMembership "user-that-runs-the-sim"
security authorizationdb write system.privilege.taskport is-developer
See References here and here.
I've recently found out that if you install a new version of Xcode and do not launch it. The simulator might start timing out again. To solve this, I've had to manually launch Xcode, and install the additional tools it requested.
I ended up solving this on Xcode 5 by doing the steps here, essentially running:
sudo security authorizationdb write system.privilege.taskport allow
This will eliminate one class of these authentication popups. You’ll also need to run:
sudo DevToolsSecurity -enable
However, once I upgraded to Xcode 6, I now get an infinite hang when trying to run xcodebuild tests over SSH. They continue to run just fine as long as I'm logged into the console, and running them from the keyboard.
I ran into the same issue. My working theory is that SSH on OSX is started as a LaunchDaemon, and LaunchDaemons are not allowed to present a UI; Reference.
I was able to work around the issue by using Java Web Start to launch the Jenkins slave. I then installed the Jenkins slave as a launchd service.
Unfortunately the Jenkins slave then installs itself as a -you've guessed it- LaunchDaemon, leading to the exact same problem of not being able to launch the tests; Reference.
I worked around that issue by moving the Jenkins Slave LaunchDaemon plist and jar files in /System/Library/LaunchDaemons into ~/Library/LaunchAgents, and updated the paths inside the plist file.
That finally allowed me to run XCode6 (Beta6) tests on an OSX jenkins slave.
I finally managed to find a good simple solution. JNLP was causing numerous issues with our jenkins server.
Workaround for SSH timeout via https://corner.squareup.com/2015/07/ios-build-infrastructure.html
"Mavericks (10.9) and Yosemite (10.10) determine if a process can access accessibility hooks via the parentage of the accessing process. By putting launchd in the list of allowed processes, processes launched via SSH or Jenkins have access to the accessibility hooks across the system. To do this you can modify the TCC database, per this gist. A reboot is required to make the change take effect."
#!/bin/bash
# This will add lauchd to the list of allowed processes for accessibility access
sudo sqlite3 /Library/Application\ Support/com.apple.TCC/TCC.db "INSERT or REPLACE INTO access VALUES('kTCCServiceAccessibility','/sbin/launchd',1,1,1,NULL)"
# This outputs the rows in the TCC database
sudo sqlite3 /Library/Application\ Support/com.apple.TCC/TCC.db 'select * from access'
echo "Restart is required for these changes to take effect"
Update 8/02/2016
This is now fixed in Xcode 7.2.1 ("Command line tool ‘xcodebuild test’ will no longer time out waiting for Simulator.app to launch")
I've seen this error before, one possibility is that since you probably downloaded the Xcode6 Beta from the internet (not the appstore as its not available yet), the machine you are trying to run it on will show a pop up asking you if you really want to open this app as its from the internet.
The same will happen when xcodebuild tries to launch the iPhone simulator app.
One thing you might want to try is to share screen with the machine and click "Open" in that pop up.
If that still doesn't work, I would try to:
Reset the Content & Settings of the simulator
Reboot the machine and make sure no simulator is running on start up (you can just choose not to re-open any app when restarting)
I'm working on a debian 6.0 installed on virtualbox 4 hosted by Windows7, and I'm trying to get my STM32VL work using STLINK project that allows programming and debugging STM32 on Linux.
I followed their tutorial and installed all needed dependancies.
But when I run the program ./st-util -1, I get the following error:
tbarry#darkstar:~/stlink$ ./st-util -1
2014-03-20T10:18:48 WARN src/stlink-sg.c: Failed to find an stlink v1 by VID:PID
Error: could not open stlink device
Error: could not open stlink device
I underline that I have already installed Virtualbox extensions, and usb 2.0 is well handled.
Does anyone have an idea of what is blocking me?
I'd same problem. It was driver problem. Windows detected my st-link as mass storage device, so st-util didn't see it. I've used zadig utility in order to change the driver.
Not having found a solution to my problem, I tried with VMware player and it worked nice.
Conclusion: Whatever the problem I had, it was coming from VirtualBox.