-
Re: QEMU only works for one build
brendansimon Feb 11, 2019 6:52 AM (in response to brendansimon)The same setup on my Windows box is ok. i.e. I don't see the above symptom.
I wonder if there is something screwed up in my Eclipse workspace? I might try creating a new workspace on macos, create a new blinky project, and see what happens.
-
Re: QEMU only works for one build
ilg Feb 11, 2019 10:25 AM (in response to brendansimon)I tried on my mac and 3 qemu debug session in a row were ok.
first check if qemu is closed successfuly, or hangs and the next session is affected.
then install a new eclipse, somewhere in a temporary folder, (unpacked from the epp archive), create a fresh workspace and a new blinky app.
-
Re: QEMU only works for one build
brendansimon Feb 11, 2019 4:13 PM (in response to ilg)I started a new workspace, created a new Blinky, clean, build, etc => problem still exists.
I deleted my Eclipse install, reinstalled Eclipse and all my plugins, opened the new workspace, clean, build, etc => problem still exists.
I rebooted the computer (hadn't been rebooted for quite some time), opened the new workspace, clean, build, etc => PROBLEM SOLVED !!
Seems as though something got screwed up in my OS .... sigh ....
-
Re: QEMU only works for one build
ilg Feb 11, 2019 11:34 PM (in response to brendansimon)the endless magic of... reset?
-
Re: QEMU only works for one build
ilg Feb 11, 2019 11:49 PM (in response to ilg)btw, I don't know if you noticed, but the graphical buttons in qemu are... live.
if your application is prepared for this, try them. I remember one of the F4DISCO templates generates code to use the user button, but I'm not sure which one.
if not, at least the reset button can be tested.
-
Re: QEMU only works for one build
brendansimon Feb 12, 2019 1:08 AM (in response to ilg)Yes I had noticed. The app I'm using lights up the green LED when the user button is pressed. This also works in QEMU
The issue I'm working on at the moment is the blue LED which is asserted during the TIM10 interrupt handler. I can't get that handler to fire, so need to delve into how QEMU handles interrupts, and whether the code in `tim10.c` is fully implemented or not. There is a bit of code there and some of it is "hash-if-zeroed" out.
-
-
-
-
-
I'm running QEMU 2.80-4 on a Mac with Eclipse 2018-12.
When I start Eclipse, clean the my project, build my project, then run/debug my project it works perfectly.
I can run/debug many times.
If I clean the project again, then build, and run/debug it, QEMU fails to start.
If I restart Eclipse, or switch workspaces and back again (which seems similar to a restart), I can run/debug without any issues (no build required).
If I clean, build and run/debug again, QEMU fails.
The above can also be repeated with the C++ Blinky project.
This happens with GCC 7.3 and 8.2, and QEMU 2.80-3 and 2.80-4.
This is the error message when QEMU fails.
Error in final launch sequence
Failed to execute MI command:
-target-select remote localhost:1234
Error message from debugger back end:
Remote replied unexpectedly to 'vMustReplyEmpty': PacketSize=1000;qXfer:features:read+
Failed to execute MI command:
-target-select remote localhost:1234
Error message from debugger back end:
Remote replied unexpectedly to 'vMustReplyEmpty': PacketSize=1000;qXfer:features:read+
Remote replied unexpectedly to 'vMustReplyEmpty': PacketSize=1000;qXfer:features:read+
Is anyone else seeing anything like this?
Thanks, Brendan.