AS7 (build 634) simulator doesn't start-debug-and-break,or stop.

Go To Last Post
25 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi, all.

I'm having problems with the simulator, such that I tell it to start-debug-and-break (or, Alt-F5), and it simply doesn't!

Program compiles with no errors, even tried Clean Solution/Clean Project to no avail before running.

Optimisation is off (O0), debug default (-g2).

All in the status bar says "Running". Even hitting 'pause' button has no effect - if I then bring up Disassembler I get "Disassembly cannot be displayed in run mode.". Processor Status window is blank.

Even putting a breakpoint at the first line of main() has no effect. Nor does "run to cursor".

I just tried loading other projects, they behave the same.

In desperation, I've even uninstall/repair'd it (I chose repair)

 

Even this snippet of crapware I wrote doesn't run in simulator.

int main(void)
{
	init_uart();
	usart_sendstring("Hello World\r\n");
	usart_sendstring("Type into Terminal\r\n");
	while (1) {
		usart_putc(usart_getc());
	}
}

Windows 10, 64-bit

Any ideas? Is it conceivable something in my code - even before the start of main - could cause this? Or a simple setting I've forgotten?

-Thanks for consideration

-Andy

 

** Update - I purged Atmel Studio off the computer, rebooted, cleaned the registry with ccleaner and totally reinstalled. No change **

Last Edited: Sun. Feb 7, 2016 - 06:18 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Disassembly cannot be displayed in run mode.".

This is correct, you must stop/pause the simulator from running first.

 

even before the start of main

What do you have there? At least you are missing one include file io.h Please post the FULL program.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Er, yes. I know. Perhaps I should've put "then" in capital letters.

Even hitting 'pause' button has no effect - if I then bring up Disassembler I get "Disassembly cannot be displayed in run mode."

I didn't post the WHOLE code. Suffice it to say, #include<avr/io.h> is at the beginning. As are the other routines. Plus, the code actually works. It was a test I wrote to ensure I'd got the USARTS wired correctly on the PCB, - which I had.

Suffice it to say, I've run/debugged this (and the project where I first noticed the simulator problem) with Atmel-ICE, Dragon, and simulator in the past. Off-topic, I'm afraid. 

But, OK, here's the code:

/*
 * AVRfreaks_USART.c
 *
 * Created: 25.6.2015 11:48:32
 *  Author: omistaja
 */ 
#include <avr/io.h>
#include <avr/pgmspace.h>
#define F_CPU	2000000UL
void init_uart(void)
{
	PORTE.OUTSET = PIN3_bm;     // TX high
	PORTE.DIRSET = PIN3_bm;     // and output
	PORTE.DIRCLR = PIN2_bm;     // RX is input
	USARTE0.CTRLA = 0x00;
	USARTE0.CTRLB = USART_RXEN_bm | USART_TXEN_bm;
	USARTE0.CTRLC = 3;
	//USARTE0.BAUDCTRLA = (((F_CPU) / (16)) / 9600) - 1;
	USARTE0_BAUDCTRLA = 12;
	USARTE0.BAUDCTRLB = 0;
}
void usart_putc(char c)
{
	while (!(USARTE0.STATUS & USART_DREIF_bm));
	USARTE0.DATA = c;
}
char usart_getc(void)
{
	while (!(USARTE0.STATUS & USART_RXCIF_bm));
	return USARTE0.DATA;
}
void usart_sendstring(char *s)
{
	while (*s) {
		usart_putc(*s++);
	}
}
int main(void)
{
	init_uart();
	usart_sendstring("Hello World\r\n");
	usart_sendstring("Type into Terminal\r\n");
	while (1) {
		usart_putc(usart_getc());
	}
}

 

Last Edited: Mon. Feb 8, 2016 - 04:47 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Obviously a Xmega chip, which one? Someone may try the above if they have the correct chip.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

256A3U. But, now this gets daft...I'm now at work with (almost*) identical setup. 

I use Dropbox to synch. the files between home and work. As both machines are running Dropbox 24/7, they are always synch'd. Yes, I've checked.

This morning, on the work machine, it's working normally with the same project code I tried to debug at home. (Not the above code...)

Both machines virus-scanned, both absolutely up-to-date, Atmel Studio reports 'no updates availaböe', both running AS/ build 634. 

Remember, the 'home' machine has also in addition, to eliminate, had a totally fresh install.

 

So, what environment variable in Windows could've changed? The only thing I didn't do after uninstall/install AS last night was to purge the Atmel directory, and all its sub-directories.

*Home machine is Win-10 pro, office is Win-10 Home (?go figure!). Both 64-bit. Both have been used to simulate the same code, until the home machine stopped simulating yesterday.

 

Last Edited: Mon. Feb 8, 2016 - 08:25 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is most certainly related to a runaway process with some of our older simulator models that has re-submerged after the last release. I find it a little peculiar though that you are affected by it when simulating xmega, because they should not be affected. The fix is done, tested and pushed, just waiting for the next release which is just around the corner (which is as accurate as I dare to be when commenting release dates...).

On the PC that are failing, where you also simulating some other devices?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi, Je

Nope, just the 256A3U....This morning, the 'work' machine started to play up,also - but somehow recovered. Another 'oddball' thing I've noticed is when using a Dragon, sometimes when using "Run-and-Break", the first line of main() isn't highlit, usually it is. Step-into occasionally seems to advance the cursor only, no yellow highlighter...
Related? D'ya think it's a Winders-10 update - altho' my last (common-to-both-machines) update was "Cumulative Update for Windows 10 Version 1511 for x64-based Systems (KB3124262)" was 30.January.

I think that when I get home, I'll roll it back and try the simulator again, and report back here.

-Thanks

-Andy

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK, update. Might give a clue....

Once again, I uninstalled AS7.

I then deleted the /Program Files(x86)/Atmel directory. (Is only 32 bit available?)

Purged the directory, and ran ccleane to clean the registry.

I reinstalled it in /Program Files/ (not x86) directory.

Ty again (Start debug and break, but with a breakpoint a couple of instructions into main() - just in case)

Same problem, BUT occasionally it would stop....

Remove last upgrade - (KB3124262 - cumulative update for 64-bit systems).

Try again - same result.

SO, I kept trying "Start-debug-and-break", when I saw "Running" in the status bar, I stopped it, ran again.

Of 20 of these runs, it stopped correctly at the beginning of main() three times. 17 times, it just went to 'running' forever.

Weird.....Pity, as I really need this at the moment. At least I can use the target sometimes.

-Andy

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It still sounds like the known issue, since it occurs a bit random, but it still puzzles me that you get this behaviour with an xmega. What you could do is to try an older version of Atmel Studio (http://www.atmel.com/tools/studi...) if you need to simulate this device now.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for reply. Should I get 4.19? Seems it supports xmega256A3U - but the memory size ain't an issue just to simulate - small program, just want the ram and the asynch. interrupts. Probably be enough just to simulate - as I mentioned, I have targets, but "She-Who-Must-Be-Obeyed" gets a bit irritable with hardware in the bedroom, so I simulate at home, test hardware at work. 

Still seems odd that one machine experiences the problem almost always, the other machine almost never...I'll also try mucking about with windows' performance settings on the 'problem' machine. If it is a race condition, I might just find a 'sweet spot'.

Thanks

-Andy

 

Last Edited: Mon. Feb 8, 2016 - 09:38 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Unless you want to you don't have to go further back than 6.2 SP2 (build 1563), which by the way should be able to live happily beside 7.0.

 

The problem that almost fits your description is related to a thread started when VTOC runtime is loaded and not terminated when unloaded. This always happens, but Atmel Studio only crashes occasionally on most machines (but constitently on some). Probably happens if the leftover thread is waken up. Additionally the presence of a breakpoint in the program is at some point noted to make a difference. This issue was first reported in AVR Studio 4.13 and was fixed back then. For Atmel Studio 7.0 we did some changes to the simulator model API which re-enabled this bug. The reason this only almost fits your description is that none of the xmegas uses the VTOC runtime, which is why I asked if you also were simulating some other device.

If you create new empty projects for a UC3L or ATmega328PB, are you able to simulate those?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks I'll use 6.2 for now.

Haven't got any 328 code lurking about, but I'll have a go at it when I've  spare moment. Should be some on the web I can purloin.

Let you know soon.

-Cheers

-Andy

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You don't need any code. Just create a new empty project, compile and start simulating and see if it breaks at main().

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yeah, of course! Me being daft...

 I chose a MEGA328P for both.

Studio 7 - stopped only on the very first try (after a reinstall - I read somewhere that 6.2 had to be put on first, then 7 because of this damn Jungo issue)

Tried about 50x.

Studio 6.2 build 1563 stops reliably every time.

(Didn't appreciate until today how much faster AS7 is to get its act together over 6.2! Vast improvement.)

Hope that helps.

(Now all I've gotta do is work out a quick way to import all my project's files from AS7 to AS6.2....Never done this before UPDATE: Splendid video from Atmel showed me. 

https://www.youtube.com/watch?v=... )

Now simulating happily with Studio 6.2 enlightened

-Andy

edit: Forgot to mention. This on the more problematic machine at home (Win-10 Pro). I do have another machine - an old-ish laptop with Win-10 Pro and latest Studio 7. Just tried it - it only has 2G ram, 32-bit. Same result - occasionally breaks.

 

Last Edited: Tue. Feb 9, 2016 - 05:36 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Rats!
Got the latest AS7.0.790 build, hoped it would contain the fix. Nope ("Empty-ish" project on a 256A3U). Fails to break on Alt-F5.
Changed to 328P - same. Optimisation set at -O0.

Now, It still states "Running" but after awhile, window pops up, "Launch Failed", as screenshot shows. In addition, I never noticed before, but the "Tool" selection goes from Simulator to No Tool, as in the screenshot attached. Simulator tool returns when notification OK'd.

 

Think I'll have to go back to 6.2 for the forseeable future - I need to switch between simulator and debugger repetitively...(if I build with 7, I can't easily switch to 6.2 without a lot of work - new project, link files across, remember to add link if I create a new tool, etc)

Sorry, but 7.0.790 is NOT a fix for AVRSV-7014, as the release note claims.
(Again, two machines, totally up-to-date, both Win-10 Pro, one a 32-bit, other a 64-bitter).

-Andy

 

EDIT: Continued this thread in this link, because of more relevance.

https://www.avrfreaks.net/forum/u...

 

Last Edited: Fri. Mar 4, 2016 - 07:27 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've made some changes, and is no longer able to recreate the problem. Would you be interested in trying the attached dll and see if it fixes things for you? Unzipping it into "C:\Program Files (x86)\Atmel\Studio\7.0\atbackend\codeCache" should do the trick, and you might want to save the old one in case you want to revert back.

 

-Jan Egil

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry, Jan - not for me.

I've tried it on three different PC's - all 64-bit processors, but one running 32-bit Win-10. (So directory Program Files, not Program Files(x86) )
All gave the same result as per screenshot attached.
Again, it seems to work fine the first time, breakpoints repetitively break as expected. After that, no.
Message appears after some 10 seconds, seems to keep coming.

Whether I answer 'yes' or 'no doesn't affect the outcome. 

-Thanks for perseverance!

-Andy

 

Attachment(s): 

Last Edited: Tue. Mar 8, 2016 - 06:32 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dang. That dll fixed the issue on one of my colleagues pc. Could you provide some logs, please.

http://atmel.force.com/support/a...

 

-Jan Egil

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sure!

Two files - the "good - first run.txt" after restarting AS7, and let it hit the start of main, then 'continue' a couple of times, hit the BP as expected.
Then I stopped, and re-ran. "bad - second run.txt"is the result, after I answered 'no' to the popup.

 

HTH...

-Andy

 

(I noticed this in the 'bad' run'...

09 03 56 671: msg send(a8):E RunControl contextResumed "RunCtrl_3"
09 04 18 511: msg recv(a8):C 130 Processes terminate "Proc_3"
-presumably this is the long delay I see between starting debug, and the popup.)

 

Attachment(s): 

Last Edited: Tue. Mar 8, 2016 - 07:15 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry Andy, but could you do another try with yet another dll?

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Aha! Quick test, looks like that's got it!

I'm off home early today, so I can try it more thoroughly on the two machines I have at home. Let you know more in a couple of hours or so.

 

-Andy

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Good that I'm finally on to something. Just as a last verification I'd like you to try this last one also.

 

I know this isn't the most appropriate way of doing debugging, but since your machines currently are the only ones I know of which are failing I really appreciate your help.

 

-Jan Egil

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

HI, Jan. 

This is a bit inconclusive, so I've done the following to ensure as much as possible is the same in AS6.2 and AS7:

DLL is the one in the-last-one.zip'

I've a half-baked project, which I had built using 6.2, then 'upgraded' to 7.0. As a result, I have both the .atsin (7.0) and the 6.2.atsin files. Using Windows 10 multi-desktop feature, I setup one desktop for 6.2, other for 7. Optimisation at 0O, debug at -g2, and I've setup the same breakpoints for each.
This project is a lot bigger than the simple file I tested last night.

(6.2), runs, stops at main() without a hitch.

(6.2) hits next BP, then after F5-continue, it ends up in a loop waiting for TWI. So I hit the 'pause' key, as expected disassembly opens and shows me it's in a loop. Correct.

(6.2) "stop" - stops instantly. use F5 (Start debugging) - doesn't stop at main - correct - stops at first BP. OK.

 

(7) stops first time at the start of main(). BUT a window pops up after it stopped. See stop.PNG

'Continue', hits next breakpoint. 'continue' (to endless loop) - hit 'pause'. Nothing, so after awhile, hit stop. About 30 seconds of 'spinning wheel' (Win-10 version of hourglass) then "Waiting for an operation to complete". So I wait one more minute. Nothing, no response at all until "Waiting..." window pops up again. So I hit "Stop waiting". After a few of these windows, AS7 comes back to life, but trying debug again, nothing until the "Waiting...." window returns. Hit "Stop waiting" and a new window appears: "Unable to connect (Unable.PNG).

I'm going to a) go back to the file you sent me yesterday, and b) see if I can find a free video recording app. so I can 'walk you through it'.
Logfile attached, natch, but what's happened to the clock after the first few lines?? Seems to have jumped to 12-hour from 24? Relevant?

 

 

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi All,

 

I am a complete nubie to Studio 7, but it seems I'm having the same problem no matter what machine I install AS7 on.

I can't get the debugger to stop on brkpt or any of the debug windows to launch --- just shows the successful "Build"

 

Tried on Win10 and Win7 machines ... my program just buzzes by the break point and runs --- I'd hate to have to use

AS6 since this is a project built from Arduino code that is imported via AS7. Any progress isolating the problem?

 

Target=atmega328 8MHz 3.3V

 

program "works" --- just can't use the debugger

 

Atmel Studio 7 (Version: 7.0.1645 - )
© 2015 Atmel Corp.
All rights reserved.

OS Version: Microsoft Windows NT 6.2.9200.0
Platform: Win32NT

 

Also I found this nugget on the release notes of AS7 on page 7 of 86 pages ...

 

• AVRSV-6676: Launching debugging fails due to issue with Intel graphics driver

 

Supposedly that error was fixed in version Atmel Studio 7.0.634  

 

When installing I got a warning about my graphics driver so I tried to update it and 

Windows informed me that I had the latest driver.  SO it seems I'm doomed by 

this sort of ready for prime time IDE?

 

 

MORE INFO

 

I was going crazy until I discovered that debugging is not supported thru the ISP (in system programming) aka SPI port connection UNLESS you use DebugWire which uses the same connection but apparently communicates thru the Reset pin (which you better pull up only lightly ~10k no cap).  Now all is working fine ...  this video explains it all ---   https://www.youtube.com/watch?v=Bo0spmIKCy4

 

Cheers

 

 

 

 

 

 

 

 

Last Edited: Wed. Jan 10, 2018 - 04:29 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have also a "Crazy" simulator behavior and i find the soltution an other post of tis forum. If your PC run with an OS 64 bits ... Studio 7 is an X 86 application install it in the X86 direcotry and load and instal manually "MS VC++ X86" 32 bits instead the 64 bits, then the simlator run....