BST question/issue
photomankc
Posts: 943
I was using and really liking BST for my propeller projects but lately I keep running into an issue. After a couple of compiles, when the pop-up shows up just before the code is loaded to the Prop BST locks up good. Some message box eventually appears behind the 'Knight Rider' window, for lack of a better term. I can't see what it says because I can't see the the title bar to move it. If you dismiss the hidden dialog then every few seconds another window spawns into the task bar and disappears. The only way to get past this is to kill the process and restart. The worst part is that this keeps nailing me as I'm testing unsaved changes so I lose my work each time it happens. So for now I just can't really use it. I was wondering if this is known issue or if there is anything I can do to fix it if possible.
I'm on Windows, both on Vista and Windows 7. This happens on both systems each using different PropPlugs and programming different boards.
I'm on Windows, both on Vista and Windows 7. This happens on both systems each using different PropPlugs and programming different boards.
Comments
Not a known issue, but need more information.
What worries me is you are losing your work. bst takes great care to save an autorecovery file prior to each compile for all unsaved tabs. If it's not popping back up and telling you its recovering files when you next load it then there is a problem there I need to look at. I know Vista and Windows 7 do incredibly un-intuitive things in the background with files supposed to be saved in user profiles, but I have no idea why it would not be saving the autorecovery file. It should scream loudly if it can't do that.
Can you do a search of your filesystem for a file called '.bst.recover' ?
I don't own Vista, or Windows 7 to test on. Which version of bst are you running?
Can you reproduce the problem using simple test code or is it dependent on the code you are developing a the moment?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
Another tidbit would be that my development work is on a shared network mapped drive. I have several computers I work from so that is a must to me rather than code scattered about on each system. That may play into it. I have BST stored on that mapped drive and always just ran the executable from there.
BST is version 0.18.4
I'll look for the recover files when I get home.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full
Morpheusdual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory IO board kit $89.95, both kits $189.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
I use and test bst on networked drives on Linux, MacOS and Windows. My entire test suite lives on a server that is accessed by SMB on Win32 and OSX, and NFS on Linux, so bst does not in any way rely on a local disk. Prior to each release, bst and bstc compiles and loads over 1800 spin files on each platform over the network, so I hope it's not that [noparse]:)[/noparse]
More info would be helpful. If you think it might be an issue with a code error causing bst to die (it will come back and just say the compile failed but not give any errors in the error window) then if you could send me the code so I can reproduce it locally I can get it fixed.
If you do ever get a compile die, save your work and restart the IDE. Cleaning up a thread after a segfault is somewhat dicey sometimes. I do the best I can, but there are limits.
I am _incredibly_ concerned that you are losing work though, as I've put a massive amount of effort into what I thought was a very reliable recovery mechanism. I even have menu items and special code defines to cause compiler and IDE explosions specifically to test the recovery code on all the platforms.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
If you get a compiler crash I'd *really* appreciate a copy of the code that causes it. Can't fix it if I don't know about it.
Of course, due to bst only archiving code that can actually compile, you can't use the archive function to zip up code that causes a crash so you need to do it by hand.
That is one of the major issues I hope to resolve for 0.19.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
·Perhaps the Knight rider could pop up somewhere else?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
This does have a couple of crashers fixed since 0.18.4 and one recently since 0.18.5-pre1
www.fnarfbargle.com/bst/snapshots
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
I'll get that to you shortly. It's not a 100% deal. I compiled and loaded RAM numerous times before I got one where it froze just prior to loading RAM. Clicking Knight Rider caused it to continue on but with "Compiler Crash" in the output pane. After that one incident it never did it again. I'll send you the source I was working on later.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Any chance you can give me a description of how you set it up so I can similarly break one of my proto boards and use that to reproduce the fault?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
Ok, so I've managed to make eeprom program/verify errors by shorting the SDA/SCL pins on the eeprom while the propeller is talking to it.
I can't get it to play up on Linux. Are you using Windows?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
I like your commitment. Breaking hardware to prove software, very noble. Stupid, but noble all the same. I'll do the hardware errors and leave you to the software magic.
What I had was a 4 x 10k SIL resistor strip (5 pins total) that should have pulled up P28, P29, P30 and P31 with the common going to VDD. By putting it in the wrong way around I had the common going to P31 and 10Ks going to VDD, P28, P29 and P30. The Prop's ram loaded ok but the EEPROM bit failed, serial comms was a bit wierd too·(I wonder why). This BST in limbo with a centre popup hiding behind Knight rider, CTRL_ALT_DEL.
I was in no way complaining, just trying to report a poss bug/problem.
And another thing ...· any chance of #def's and its matching partner "lighting up" like brackets do ???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Stupid as it may sound, I don't mind breaking hardware if it will help me reproduce / fix a bug in my software. Having said that I've not broken anything yet, just upset it temporarily with a poke from a blunt needle. I get upset when I get poked with needles too.
I do have 5 spare QFP props here, flux in the fridge and my hot air rework station is waiting at the UPS depot for me, so I am now equipped to fix it if I break it anyway.
I'm investigating that bit it's going to require I add quite a bit more intelligence to the highlighter. It's on the todo list, but I can't guarantee when I'll get to it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
The code that crashed the other night is attached to this post.
http://forums.parallax.com/forums/default.aspx?f=21&m=399198
Excellent, at least I know what I'm chasing now. I can't reproduce this on Linux at all. I'll have to borrow a 'doze box and see if I can break it on there.
OSX and linux share the same serial loader code as they are both POSIX compliant. Windows pretends to be POSIX compliant but breaks things enough that I need a completely different code path, and I don't test it as heavily as the others as I don't own a copy of Windows.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
Post Edited (BradC) : 11/7/2009 5:22:15 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
This has a fairly significant rework of the load error handling code.
Toby, I think your error was different to photomankc.
Either way, the end result for both errors was the dialog box hiding behind the knight rider box because of a dud order I had in the error handling code.
It was not actually a crash. On windows, if any menu is activated (like when you hit F10 while it's loading - it activates the application menu) the application stops responding to GUI messages until the menu is cleared (esc/F10/mouse click/etc...). This was causing the service thread to timeout and thus the crash message. Now, in the same situation, the GUI will still freeze until you click or whatever, but the underlying thread knows whether this is a crash or a GUI freeze and does the right thing.
Now, the load code properly closes the knight rider window before reporting the error, and rather than a generic "load error" it will actually tell you what went wrong.
In either case, rather than a ctrl-alt-del, a simple <enter> would have dismissed the dialog, but we could not see that as it was hidden. For this release I've left the knight-rider dialog up in the top corner, but it should *always* disappear prior to any form of error box popping up.
Give it a whirl. I have the Windows box for another couple of days if it's still a problem.
Linux and Mac users, no need to upgrade, but it will give you better error reports if you want them.
<warning> Bleeding edge, relatively untested code than has not been through any QA.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
Ok, so I'm going to keep trying.
Using F10 or F11?
Prop Plug?
bst-0.18.5-Pre1-test2?
Tried another USB cable?
32 or 64 bit Windows?
The timeout on the loader crashes message is 10 seconds of no-response. Is it actually waiting 10 seconds?
Do you have double-baudrate downloads enabled ? (Compiler options dialog)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
This has a significant rework in the keypress handling.
On Vista, it looks like the first F10 keypress was bringing up the compiler and also the application menu at the same time, jamming things right up. I've found a reliable way of preventing the application menu coming up on the first F10 keypress.
This problem never manifested itself on XP (which is what I test the Win32 version on).
I still can't make the loader crash however. photomankc, I've compiled and loaded your attached code above to RAM and EEPROM about 100 times and not run into an issue on 32 Bit Vista Home Premium. If you can still reliably make it crash without much effort, I'll keep bashing away until we can solve it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
Post Edited (BradC) : 11/14/2009 3:21:11 AM GMT
PropPlug, 2 different plugs
bst-0.18.5-Pre1-test2
Happens with any USB cable
Both 32 and 64bit Vista and Win7
Yes, it does seem to wait 10 seconds.· In the meantime the Prop resets and starts over.
No Double Baud Rate is not enabled.
Some type of blank pop-up fires off when I start the app too sometimes.· Closing it via the red X then loads up the IDE.
·
I've just seen this. The "blank pop up" actually is supposed to say "It appears we are recovering X files". I don't yet know why it is not displaying the contents of the message.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
Solved the blank dialog issue on Vista. There appear to be some not-insignificant oddities with Vista that don't exist with XP. <shrug>
Added a metric ton of extra debugging and error handling surrounding the serial loader to try and get a useful error. Can now pull the USB lead out mid-load and get a message rather than a lock up.
Added the same handling to the serial terminal so when you pull the USB lead out while it's connected it won't do nasty things.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.