I've just installed MPLAB X IDE v5.30 on my computer, connected a Curiosity HPC development board, which has an integrated programmer (PICkit-on-board, PKOB), and tried to use it on a project, however, on the project settings menu, the board is detected and listed under "Starter kits (PKOB)" but shows as unsupported (like the venerable PICkit2)
Has microchip discontinued this product or is it some sort of configuration error? How can I solve it?
Project is using a PIC18F23K22 microcontroller, and the compiler is XC8 (free).
After running it through MPLAB IPE v5.20 once, by selecting the microcontroller and clicking "Apply" then "Connect" the IPE tool updated the board firmware from 01.51.07 to 01.56.00.
IPE v5.20 (old) output:
Once completed, the tool is detected by IPE version v5.30 without any apparent issue, even updating it to firmware revision 01.56.02. At this point the tool is detected no issue by the IDE as well.
Related
In using the Pickit4 for flashing the code.
When I first open the MPLAB X IDE and use the Make and Flash button to flash the MCU, it works fine.
But the next time in the same session, the Make and Flash button goes grey and does not do anything and I get and error saying:
Failed to initialize PICkit 4.
Then when I try to clean and build, I get an error saying:
Script engine is not supported.
I have tried deleting the persistent files and starting fresh, but the errors remain. I tried with multiple different projects, but I still have the same issue.
I'm not sure what do do next?
Is it a PICkit 4 issue?
How can I fix this?
I started seeing the same thing today. Worked fine for months until now. No MCC installed. Turns out some packs were out of date. I updated them and everything is back to normal so far.
PicKit 4
Product Version: MPLAB X IDE v6.05
Windows 10 Pro 22H2
PIC16F887
This is an issue of the MCC:
If you want to work with MPLABX5.05 you need MCC 5.2.2 (or the other way around)
It also may be neccessary when upgrading to MPLAB X IDE v6.05/MCC v5.2 on an existing MCC Classic configuration it may be necessary to update your MCC libraries for some GUIs to display properly
Recently I was attempting to upload some code on my Arduino and got this error:
****Arduino: 1.8.9 (Mac OS X), Board: "Arduino/Genuino Uno"
fork/exec /Users/Gu/Desktop/Every single yhing/coding stuff/Arduino.app/Contents/Java/hardware/tools/avr/bin/avr-g++: bad CPU type in executable
Error compiling for board Arduino/Genuino Uno.
This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.****
I quickly learned that is was due to the macOS update Catalina no longer supporting 32-bit applications and the avr-g++ keychain tool is run through a 32-bit process.
If anyone has any solution to fix this problem please assist me.
Had the same problem trying to get the IDE compiling for an ESP8266, I followed the thread from the Arduino Forums linked here:
https://forum.arduino.cc/index.php?topic=620175.0
Long story short, I updated the Arduino IDE to version 1.8.13 and it worked for me on Catalina.
For me it worked on Catalina by:
updating the Arduino IDE to 1.8.13
Inside the IDE, updating "Arduino AVR Boards" to the latest version (on a Mac, Tools -> Board: "xxxx" -> Boards Manager... -> Arduino AVR Boards)
Access to Boards Manager in the IDE
Arduino AVR Boards update location
Problem
Instruments' Time Profiler is stripping all symbols except system libraries from my app, despite the fact that I have disabled this behavior in all relevant build settings in Xcode — but only on one development machine. The other dev machine behaves normally.
Description
Instruments' Time Profiler is stripping all symbols except system libraries, despite the fact that I have disabled this behavior in all relevant build settings in Xcode — but this is only happening on one of my development machines. I have two development machines running the same version of OS X, Xcode, and Instruments, and each machine is using an identical copy of the same Xcode project with identical build settings, schemes, and other configurations, and the app is profiled using the same test device (iPhone 4S with the latest public version of iOS 5).
Machine 1
- Mac OS X 10.7.4
- Xcode 4.3.2 (4E2002)
- Instruments 4.3 (4321)
Machine 2
- Mac OS X 10.7.4
- Xcode 4.3.2 (4E2002)
- Instruments 4.3 (4321)
Steps To Reproduce
Open included sample project on each machine.
Make sure the iPhone 4S is selected as the test device.
Select Product > Profile
When Instruments launches, select Time Profiler and continue.
Run the app.
Notice how the symbols are stripped when running on the iMac (Machine 1) but not on the MacBook Air (Machine 2).
Expected Behavior
Symbols from my own code should appear in the Time Profiler on both machines.
Regression
I have tried all of the following, with no change in the actual results:
Rebooting the machine.
Trying other Xcode projects
Deleting the "Derived Data" for all projects in the Xcode Organizer.
Re-symbolicating the document in Instruments (carefully selecting the correct DSYM file in ~/Library/blahBlahBlah…)
Final Notes
Here is a link to a .zip file of a sample project: Sample Project .zip
I was finally able to get it to work by a method that's just shy of a nuke-and-pave scenario:
Make absolutely sure all symbol stripping is disabled for your current build configuration. Make sure you've done this for your Release config if that's what's being profiled for Instruments.
Delete the app from the iOS device.
Restart the iOS device.
Restart the Mac (I don't trust Xcode or Lion at all to quit all relevant processes otherwise).
Launch Xcode, go to Organizer > Projects and delete Derived Data for the affected project.
Clean your project. Hell, why not?
Build and profile for Instruments.
Choose the Time Profiler in Instruments for clarity.
The first run will not show the symbols, but don't quit. Leave Instruments running!
Re-symbolicate the document in Instruments, navigating carefully to the correct dSYM file for the current build. This should be easier since you've deleted the derived data in step 5.
Now you should be able to see your symbols. It helps if you hide non-objective-C symbols.
Why do I suggest that you delete the app and restart the iOS device in Steps 2 and 3? I have a suspicion that Xcode doesn't perform a clean installation of each build, but may install deltas, such that the symbol addresses present in Instruments are a mixture of the current build plus previous builds. If so, then this issue is even more common for someone like me, who shares a single test device between more than one Mac. This assumption could be wildly incorrect.
If the above steps don't work for you, please let me know in the comments. I'd like to create a detailed radar report at some point in the future.
I'm not sure that it has been fixed in the 4.3 but this is a known problem in 4.2 seen here
Instruments
There is a known issue with the Profile action from Xcode 4.2. After a build in which no source files have changed, Instruments will be unable to gather symbols for the target application.
This affects projects where both:
The Release configuration is selected for the Profile action.
(default)
The Strip Linked Product build setting is set to "Yes”, or
a custom Run Script build phase strips the product. (non-default)
The workaround is to do any one of the following:
Perform a "Clean" on the product before initiating the Profile
action.
Do a Clean of the product and temporarily set the Strip Linked
Product build setting to "No" while Profiling.
Set the configuration of the Profile action to Debug.
Run successive profiles directly from within Instruments when you do
not need to rebuild. When developing Mac apps, using the GC Monitor
template in Instruments may cause Instruments to crash. To
workaround the problem please consider migrating your application to
ARC.
I've had a similar problem for days. I was able to profile the Debug configuration, but not Release. First I tried to make a copy of the release configuration (as suggested somewhere on the web), but that copy did not work either.
Then I made a copy of Debug, called it Profile, tried it and the symbols of Profile were shown in the profiler. Great! I then changed the optimization levels etc. to the same as Release, and now it works! Just wanted to share this, as this comment would have spared me hours...
Have been facing the same and stumbled upon this thread.
I realized that I first profiled the app with release build and after changing the scheme in Xcode for the same app, the profiler was still unable to symbolize. I have tried all obvious solutions you mentioned above but in vain.
The profiler somehow is still referring to the first build (release build)'s settings and hence it is not able to symbolize. So, I just changed the app's bundle identifier for testing purpose so that a new app is created altogether for profiling purpose. I could check the code where leaks exist now.
Try it out and let me know if this works for you too. Still pondering over why Instruments is failing to symbolize though.
I had a similar issue where I had no symbols in my os x application that I built from the command line (so in this case it is not an iphone or xcode issue). It turned out the problem was due to a bad DYLD_LIBRARY_PATH that contained my PATH. When I got rid of all those non-library paths, such as /usr/bin/, it worked.
I have a lot of third party frameworks whose symbols and binaries are unfortunately getting lost.
Additionally, my app's binary was getting lost.
I.e. if I selected File > Symbols, clicked my target, and found the similarly named item, the Binary Path was showing up red.
The solution was to go to Instruments > Preferences > Symbols, and add /Users/<MY_USER>/Library/Developer/Xcode/DerviedData to the search paths. Library is not indexed by Spotlight. After doing this, I have at least had the symbols for my app. The little circle next to my app's name goes from Yellow to Green when I do this, and persists between restarting Instruments, unlike other solutions to manually set the binary.
Let me know if you can tell me how to get all the ones for my third party frameworks. I use Carthage for some, others installed manually. Have had no luck with these yet.
I've managed to solve this by:
Disconnecting the device
Deleting the iOS Device Support files for the device's version of iOS in ~/Library/Developer/Xcode/iOS Device Support
Reconnecting the device and letting Xcode reinstall device support.
To be safe I first quit Xcode and Instruments, deleted derived data, and did a clean build as mentioned above, but no need to delete the app or restart any devices this way.
Try open XCode 3 and him Organizer. And try add from this Organizer a devices to both machines.
Just open Organizer and wait him processes. If you're see a button "Use for development" then click him.
Sometimes, XCode 4 can't add a device a truely for full development.
I am trying to find a bluetooth packet sniffer to capture bluetooth signals from close by devices. I would like for this application to work on mac osx. I have had difficulty finding anything at all so my requirements are low right now - something that shows signal strength and mac address would be a good start.
Apple publishes an application called PacketLogger.
You can download it by going to https://developer.apple.com/download/more/?=for%20Xcode (or if you have Xcode installed, go to Xcode > Open Developer Tool > More developer tools), then loging in with your Apple developer account, search for Additional Tools and download the latest version (or if you have Xcode installed, download the version matching your version of Xcode).
Although the tool is associated with Xcode, Xcode is not required to install or use it.
Prior to Xcode 8, this package was named "Hardware IO tools".
If you want the new tools to appear in Xcode's developer tools menu, drag them to the Xcode.app/Contents/Applications folder.
If you have xcode installed, hold the option key while selecting the bluetooth icon in the menu (upper right).
You'll see some new options in the drop down menu.
(At least for 10.5.8)
At the WWDC 2019 Apple announced big updates for the PacketLogger.
Just look for "Additional Tools for Xcode 12.5"
You can get it here
After downloading move PacketLogger to your Application folder and you can start using it.
I assume you are interested in BLE or Bluetooth SMART. XCode has a tool called PacketLogger and it is very easy to use. Here is an example of its output
Otherwise have a look at the Ubertooth One. You can get it here:
http://greatscottgadgets.com/ubertoothone/
This article will get you started on how to do it:
http://blog.cozybit.com/how-to-crack-bluetooth-le-security-using-crackle/
Or have a look here for some information:
https://www.usenix.org/conference/woot13/workshop-program/presentation/ryan
It is possible to use Wireshark in conjunction with the Ubertooth on OSX to capture both Bluetooth v1-3/Classic and Bluetooth LE/v4/Smart. Unfortunately it seems that the latest version of Wireshark/libpcap cannot currently utilise any built-in MacOSX Bluetooth hardware.
The Xcode utilities for Xcode 3.2.x includes three Bluetooth utilities including a packet logger.
I recently started creating applications for mobile devices and have successfully completed an application for the iPhone. I am now turning my attention to the Blackberry but haven't been able to find a convincing article or website that states that it can be done or a tutorial on how to do so. Can Blackberry apps be developed on Mac OS X? If yes, how do I go about doing so? Can anyone please point me in the right direction as I only have access to a Mac and really want to get this project on the road. Thanks in advance for your help.
UPDATE:
RIM has released a MacOS Eclipse plug-in for Blackberry Development: http://na.blackberry.com/eng/developers/javaappdev/macosx.jsp
While there is no built-in simulator, the plug-in DOES support USB tethered device debugging for the Torch 9800 handhelds. I plan to get one; they are ~$499 w/no contract. With a Torch and the new plug-in, Blackberry development is possible without using a VM. (Finally!)
PREVIOUS POST:
Building on MacOS works well once you set it up. I've had less luck with the simulator. On the whole though, being able to run Eclipse natively in MacOS and flip to a Windows VM only for debugging is a big win in my book.
You can get a MacOS version of preverify (see link below for details). I do my development with Eclipse on MacOS X and use Ant to build BB apps.
This blog is excellent and has many of the details to get you started:
http://www.azizuysal.com/2009/07/blackberry-development-on-mac-os-x.html (original link is dead. The "wayback machine" provides us with the original text content, but images and styling are lost to the sands of time. Still worth a read.)
The tricky part is getting the simulator to work. There is a Wine-based work-around, but on my computer, while the simulator was able to run under Wine, the LCD output was scrambled.
Currently, I build COD files from Mac, and my Ant build process drops them into a directory that is shared with a WinXP VM. I can run the simulator stand-alone in this VM. Debugging is also possible by installing Eclipse inside WinXP and pointing the debug configuration it at the source directories.
I've actually got a bit more magic. I enabled some of the Java 1.5 features by compiling against 1.5 and then translating the bytecode to 1.3 prior to the preverify script. (Blackberry only speaks a barbaric 1.3 java, flashback to circa 1992). It's not a silver bullet as some features still don't work, but it does cut down on the need to make everything an untyped Object reference.
Lately, I've been working on a x-platform framework to allow me to write app code once and build against both Android and Blackberry (both are Java). The Android part was easy. It's just a bitch to debug anything in Blackberry. Someone working at RIM decided that Blackberry didn't need to keep Exception stack traces unless there was a catch(Throwable), and then they could do something bizarre, non-standard, and undocumented (catching Throwable behaves weird). I've only kinda-sorta figured out a hack to get stack traces using JavaLoader.exe without breaking into the debugger, and it's barely worth it.
p.s., I now do x-platform development with a single code-base targeting Android, Blackberry, and Desktop. Desktop is great for testing app functionality, with very little Blackberry on-device testing needed once features work in the desktop 'simulator' (a Swing GUI built for debugging our games).
Even though certain components of the RIM development platform are java-based, such as the JDE - other components such as the preverifier and device simulators are implemented as native Windows executables.
Basically, the easiest way to do it is to install Windows on your Mac using Bootcamp or Parallels and run inside a real Windows environment on your Mac.
However, there are other "hackier" ways to do it using Wine, MacPorts, and a number of other tools - as an example see this blog post