The simulator is an absolute disgrace! | developer.brewmp.com The simulator is an absolute disgrace! | developer.brewmp.com

Developer

The simulator is an absolute disgrace!

Forums:

Try to run the simulator (using MVS) and you can get any of:

 

1) It launches but displaying the message "Simulation Target Powered Off", and you can't go any further.

 

2) It doesn't launch and the following is displayed: "Unknown error installing module :21"

 

3) It doesn't launch and the following is displayed: "No targets with bridge "SIM" matching ID "N"".

Where N can be one of a plethora of numbers such as 5088, 5060, 3364, 5744 ......

 

4) It doesn't launch and the following is displayed: "Connection to target failed (135)"

 

5) It launches but then the simulator window remains after MVS has stopped runing.

 

6) The simulator window (or should I say windows because you can build up N of them) remains even after MVS has exited.

 

7) The simulator window can't be closed, you have to go to the task manager and forcefully kill it.

 

8) MVS goes through phases where it crashes very **** frequently. Now I know I can't proove an MVS studio crash is the fault of the BMP simulator. But I just KNOW it is. Its got to the point where I can virtually predict when MVS is going to crash based upon the behaviour of the simulator.

 

I'm not exaggerating in the slightest to say that if I am involved in a heavy debug session, the above can happen 100 to 200 times a day. Yes, 100 to 200 times a day!

 

This is shocking. 

 

yes there are some of these issues with simulator & MSV while debugging & running a App.
below is a workaround to avoid such issues with Sim 6 & MVS.
- Start Sim 6 explicitlly with the Target on which you wish to debug or Run you App, either by using Target Manager or run command %BREWMP_TOOLSET%\bin\Simulator.exe" "Candy Bar (1.0.2.488)".
 
- Once the Simulator has started, you may Run & Debug your App directly from MSV, selecting the same Target (eg: Candy Bar (1.0.2.488)) from the MSV - BrewMP Settings.
 
You do not need to close the simulator. You can keep the simulator running & use it multiple times to run or Debug your App.This method is less prone to such errors.
 

yes there are some of these issues with simulator & MSV while debugging & running a App.
below is a workaround to avoid such issues with Sim 6 & MVS.
- Start Sim 6 explicitlly with the Target on which you wish to debug or Run you App, either by using Target Manager or run command %BREWMP_TOOLSET%\bin\Simulator.exe" "Candy Bar (1.0.2.488)".
 
- Once the Simulator has started, you may Run & Debug your App directly from MSV, selecting the same Target (eg: Candy Bar (1.0.2.488)) from the MSV - BrewMP Settings.
 
You do not need to close the simulator. You can keep the simulator running & use it multiple times to run or Debug your App.This method is less prone to such errors.
 

That did the trick
 
... for about 10 minutes until the Target Manager crashed and now won't run (it launches but it and its splash screen just hang there and according to task manager are unresponsive and have to be killed).

That did the trick
 
... for about 10 minutes until the Target Manager crashed and now won't run (it launches but it and its splash screen just hang there and according to task manager are unresponsive and have to be killed).

not very correct to advise. a quick soln: delete the Target & create a new target. then retry.
 
- did somehow your App is did something, try deleting it from target DIR & try again.
- did you manupulate anything in the Target sys dir?

not very correct to advise. a quick soln: delete the Target & create a new target. then retry.
 
- did somehow your App is did something, try deleting it from target DIR & try again.
- did you manupulate anything in the Target sys dir?

Neither my app nor myself is or has doing anything regardng targets etc.
 

Neither my app nor myself is or has doing anything regardng targets etc.
 

Here's my response on a related thread: https://developer.brewmp.com/forum/error-no-targets-device-bridge-sim-ma...
 
And I've forwarded your post to our development team.
 
Thanks,
Karina

Here's my response on a related thread: https://developer.brewmp.com/forum/error-no-targets-device-bridge-sim-ma...
 
And I've forwarded your post to our development team.
 
Thanks,
Karina

I've tried deleting the target and creating a new (different one), doesn't make much difference, neither does the suggested workaround make much difference, and I make sure the targets match etc. etc. and my machine presumably isn't slow as its a new i5 laptop.
 
I still get assorted different problems from the list mentioned previously.
 
The most annoying problem is MVS crashing (don't try and palm this off as a Microsoft bug please).
 
These are not incidents specifc to me and my machine, I used to get similar problems with another machine, and work colleagues get similar problems, but it does seem to be worse on my machine.

I've tried deleting the target and creating a new (different one), doesn't make much difference, neither does the suggested workaround make much difference, and I make sure the targets match etc. etc. and my machine presumably isn't slow as its a new i5 laptop.
 
I still get assorted different problems from the list mentioned previously.
 
The most annoying problem is MVS crashing (don't try and palm this off as a Microsoft bug please).
 
These are not incidents specifc to me and my machine, I used to get similar problems with another machine, and work colleagues get similar problems, but it does seem to be worse on my machine.

I wonder how long this list of errors can grow, here's a new one that was displayed trying to launch the simulator.

Target not enabled. Use "ct sigenable" or "ct desenable" to enable

I wonder how long this list of errors can grow, here's a new one that was displayed trying to launch the simulator.

Target not enabled. Use "ct sigenable" or "ct desenable" to enable

Potassium, that last error is an enablement issue with the device. 
https://developer.brewmp.com/resources/tech-guides/connect-technology-gu...
 

Potassium, that last error is an enablement issue with the device. 
https://developer.brewmp.com/resources/tech-guides/connect-technology-gu...
 

Thanks.
However if its for device enablement then presumably the simulator should not have displayed this message?
 
I don't have a device, I've been developing exclusively on the simulator, which just decided to randomly generate this as yet another reason for its failure to launch properly.

Thanks.
However if its for device enablement then presumably the simulator should not have displayed this message?
 
I don't have a device, I've been developing exclusively on the simulator, which just decided to randomly generate this as yet another reason for its failure to launch properly.

And yet more problems to add to the ever growing list:
1) Running the project doesn't launch a new simulator window, this sometimes happens when an old simulator window remains after a previous run (which as we all know happens most of the time anyway). The old simulator window is unresponsive. There's no alternative to this problem but to forcibly kill the old simultor via window's task manger (as is it non responsive to being closed via gentler methods).
 
2) But doing this creates yet more problems - when the project is run the simulator window is blank (not the entire similator window, just that portion representing the device screen). As an attempt to solve this an attempt can be made to remove the target and re-create it via target manager.
 
3) However not as easy as it sounds - the deletion option appears but is non selectable often.
 
4) Back to windows task manger to see if there's anything else residual to kill, how about SimTargetExecutor.exe, lets try killing that.
 
5) Sometimes this solves things, other times it doesn't, next cue hangs in the target manager, a MSVC crash, a re-boot of the computer, and of course, as always, lots of frustration and delays to development.
 
 

And yet more problems to add to the ever growing list:
1) Running the project doesn't launch a new simulator window, this sometimes happens when an old simulator window remains after a previous run (which as we all know happens most of the time anyway). The old simulator window is unresponsive. There's no alternative to this problem but to forcibly kill the old simultor via window's task manger (as is it non responsive to being closed via gentler methods).
 
2) But doing this creates yet more problems - when the project is run the simulator window is blank (not the entire similator window, just that portion representing the device screen). As an attempt to solve this an attempt can be made to remove the target and re-create it via target manager.
 
3) However not as easy as it sounds - the deletion option appears but is non selectable often.
 
4) Back to windows task manger to see if there's anything else residual to kill, how about SimTargetExecutor.exe, lets try killing that.
 
5) Sometimes this solves things, other times it doesn't, next cue hangs in the target manager, a MSVC crash, a re-boot of the computer, and of course, as always, lots of frustration and delays to development.
 
 

Here's some more:
1)
https://developer.brewmp.com/forum/why-does-handleevent-go-infinate-loop...
Given this issue I am unable to proceed with debugging my app.
 
2) 90% of the time, after running the simulator, the next time I run it it has a blank grey screen, and I have to go and kill SimTargetExecutor.exe using the task manager and run it again.
 
3) Not directly related to the simulator, but certainly a major part of using the simulator.  it is exceedingly irritating that packages are not copied to /usermods unless the project has been set as the start up project.
If you are using MVS with a solution that has several projects and you make a change to one of them, the system does not detect the change and copy the new executables into /usermods with the consequence you run with out of date executables unless you go through each affected project, set it as the start up project, run it, then stop the simulator, set the next project as the start up, run it, ......

Here's some more:
1)
https://developer.brewmp.com/forum/why-does-handleevent-go-infinate-loop...
Given this issue I am unable to proceed with debugging my app.
 
2) 90% of the time, after running the simulator, the next time I run it it has a blank grey screen, and I have to go and kill SimTargetExecutor.exe using the task manager and run it again.
 
3) Not directly related to the simulator, but certainly a major part of using the simulator.  it is exceedingly irritating that packages are not copied to /usermods unless the project has been set as the start up project.
If you are using MVS with a solution that has several projects and you make a change to one of them, the system does not detect the change and copy the new executables into /usermods with the consequence you run with out of date executables unless you go through each affected project, set it as the start up project, run it, then stop the simulator, set the next project as the start up, run it, ......

Here's some more "behaviour": 
I was unable to get notifications on the simulator working using AEET_NMASK_SS working via the .mif, I could get other notifications working such as AEET_NMAKE_NEW_CALLDESC, but AEET_NMAKE_SS simply refused to work. Until in the run tab of Brew MP properties I swithched 'Attach debugger on start up' on.
All other notifications will work with that disabled but AEE_NMAKE_SS will not work unless this option is set to true.
 
Its little(?) things like this that make developing on brew so time consuming and frustrating.
 
But wait, it gets worse -
Setting ' Attach debugger on start up' to on prevents .mifs being copied to /usermods even if the project is set as the start up project (see previously described issue). If you edit the .cif you consequently have to:
- disable the attachement of the debugger
- set the project as the start up project
- run it
- stop debugging
- switch debugging attachment back to on
- set the start up project to what it is you actually want started
- now you can execute
 !

Here's some more "behaviour": 
I was unable to get notifications on the simulator working using AEET_NMASK_SS working via the .mif, I could get other notifications working such as AEET_NMAKE_NEW_CALLDESC, but AEET_NMAKE_SS simply refused to work. Until in the run tab of Brew MP properties I swithched 'Attach debugger on start up' on.
All other notifications will work with that disabled but AEE_NMAKE_SS will not work unless this option is set to true.
 
Its little(?) things like this that make developing on brew so time consuming and frustrating.
 
But wait, it gets worse -
Setting ' Attach debugger on start up' to on prevents .mifs being copied to /usermods even if the project is set as the start up project (see previously described issue). If you edit the .cif you consequently have to:
- disable the attachement of the debugger
- set the project as the start up project
- run it
- stop debugging
- switch debugging attachment back to on
- set the start up project to what it is you actually want started
- now you can execute
 !

Here's another issue ...
If you launch the simulator and put breakpoints in the initialization points in your code you can see the system lauching everything via ModCreateInstance(). Then if from within the the simulator you choose power down, everything unloads. But then if then power back up nothing happens, i.e. no ModCreateInstance() etc.
 
How can I fully test code that launches at start up given this behaviour?

Here's another issue ...
If you launch the simulator and put breakpoints in the initialization points in your code you can see the system lauching everything via ModCreateInstance(). Then if from within the the simulator you choose power down, everything unloads. But then if then power back up nothing happens, i.e. no ModCreateInstance() etc.
 
How can I fully test code that launches at start up given this behaviour?

Here's another file copying issue - if you clear out the files in /targets/device/fs/usermods/project/ and set MVS Brew Property "Attach debugger on lanuch" then only the .dll is copied, set this to off and the other files which are supposed to get copied (.mif, .bar, any files you've specified in the project) this time do (but only if the project is set as the start up project).
 
 

Here's another file copying issue - if you clear out the files in /targets/device/fs/usermods/project/ and set MVS Brew Property "Attach debugger on lanuch" then only the .dll is copied, set this to off and the other files which are supposed to get copied (.mif, .bar, any files you've specified in the project) this time do (but only if the project is set as the start up project).
 
 

And is this another "feature" of the simulator
 
https://developer.brewmp.com/forum/observing-significantly-differing-beh...

And is this another "feature" of the simulator
 
https://developer.brewmp.com/forum/observing-significantly-differing-beh...

Can you try to see behaviour on other simulator? Whats the current ver of simulator you are using?

Can you try to see behaviour on other simulator? Whats the current ver of simulator you are using?

Hi
I've answered in the other thread

Hi
I've answered in the other thread