I am in the process of switching my development envrionment from Windows 7 running Atmel Studio to Linux Mint (v18.3 Cinnamon) running emStudio (v3.34a). Unfortunately, when I try to compile even the simplist of programs on Mint, emStudio immediately closes and the Crash Reporter popup opens (I have sent a report). On the same system I'm running VirtualBox and have created a VM running Ubuntu 16.04 and installed emStudio there as well. Accessing the same project through a shared folder, I can compile and run the program using J-Link on an Atmel SAM4S-EK2 board with no problems. I looked in the Mint syslog file and see multiple instances of the line "usb 1-12.2: usbfs: process 16257 (emStudio) did not claim interface 0 before use" that were posted at the time of the crash. I assume this has something to do with my system configuration as I have seen other posts from users that indicate they are running fine on Mint (earlier versions though). Can anyone point me towards what might be causing this problem or where I need to look for further clues?

Thanks,
Dave

Hi Nino,

Yes, the J-Link package is installed on the Mint system. When I start emStudio on Mint, the J-Link is initially disconnected. I can select Target->Connect J-link and the indicator at the bottom of the screen shows "CortexM4 on J-Link". Further, the Target Properties shows the correct information on the J-Link. Further, I just found that I can download the elf file (using Target->Download File) created under Ubuntu and when I verify it I get a popup indicating that the Verifier found no errors. If I try to download the project I get a "Project out of date" message which requires a rebuild and that leads to a crash. I should also point out that after this crash I checked /var/log/syslog and did NOT see the message about emStudio not claiming interface 0 so perhaps that was not related to this issue. As near as I can tell, everything works in emStudio right up to the point where I start to build the project and then the crash is immediate.

Regards,
Dave

[Update]

I've been trying to generate more information about this. The first thing I did was echo the build commands in the output window on Ubuntu. I then went back to Mint and executed the commands individually in a terminal window. All executed fine with the exception of the "mkld" command. On the other hand, this command had the same issues being run in a terminal window on Ubuntu as well. With the file .ld already in the Obj directory (after running the build in Ubuntu emStudio) I was able to complete the remaining two build commands (ld / objcopy) with no problems. The purpose of this exercise was to verify that there were no issues with any of the external commands being invoked by emStudio on Mint.

Next, I decided to see if I could learn anything from the *.dmp file in my ~/.segger directory. Doing a hexdump showed it was an MDMP file but I didn't really find anything that would allow me to analyze it on Linux so I copied it to a Windows 10 VM and installed the Windows debugging tools. When I ran WinDbg on the file it was unable to load the symbols but did produce this message:


This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(f0f0f0f0.7e3a): Unknown exception - code 0000000b (first/second chance not available)
*** WARNING: Unable to verify timestamp for emStudio
*** ERROR: Module load completed but symbols could not be loaded for emStudio
emStudio+0xcc4a88:
00000000`010c4a88 3800 cmp byte ptr [rax],al ds:00000000`010d1e80=??

Unfortunately I'm way out of my areas of expertise here but it looks like it shows where (offset from the start of emStudio) where the issue occurred.

Does any of this help?

Regards,
Dave

I looked at minidump-2-core but I don't think it would do anything more for me than WinDbg did. Like you pointed out, without the debug symbols there's not much of a chance to figure out what's going on. My only hope at this point is that Segger is able to come up with something in the dump file I sent them, or that a future release of either emStudio or Mint somehow resolves the problem.

Dave

I have no idea whether WinDbg can deal with a Linux dynamically linked executable. Actually, before I looked at the hexdump of the binary file, I had no idea what a minidump even was. I spent just enough time to figure out how to track down a tool that would let me look at it. After a quick scan with WinDbg I found that there was no way I would get any clues from it as to what was happening in my situation so I dropped it.

Dave