Hey Brad, question if you have a minute. Sorry if this is covered already. I am using the very latest and get crashes a lot that I never got before. The issue is, I get a popup that says it can't program the chip (not ram related, not "cannot find Propeller), and when you get this popup is says you have the option to continue and risk corruption or cancel and kill the program. If you cancel, you lose whatever was not saved. If you continue, then you no longer can get focus on the app, and essentially the app is dead but visible still, so you must Close it from the tab at the bottom of the screen. Either way, you lose where you were. I get it to work again by disconnecting the usb and reconnecting, then reboot the app. It works for an hour maybe, I have just gotten used to the process. If you have any suggestions that would be great. I cannot duplicate the crash, it is random it seems.
Not sure how this happened, but on one crash last night, even after saving regularly, on reboot I get the message "we appear to be recovering from a crash", so it gave the option to resave using the same file name. I hit resave, but then realized too late that the program was definitely older than my last save. So I lost several hours, I can see that it is not a good idea to save over the same name as gets populated in the recover. The point being that I was wondering if it has already been discussed as to how to recover from some hidden file the latest file in a case like this?
Hey Brad, question if you have a minute. Sorry if this is covered already. I am using the very latest and get crashes a lot that I never got before. The issue is, I get a popup that says it can't program the chip (not ram related, not "cannot find Propeller), and when you get this popup is says you have the option to continue and risk corruption or cancel and kill the program.
Wow. Well, that popup is a last resort error handler when things blow up badly (which appears to be happening in your case). That is not as distressing as finding the recovery save is not working properly for you.
Every time you compile a file, the editor packs all unsaved & modified tabs into a recovery file and stuffs them on the disk before it tries to compile. When bst restarts it checks for this file and if it finds it comes up with the "Recovering from a crash" message.
The recovery file is only removed on a clean close of bst.
Now, in your case I suspect what happened was this.
- You did a compile without having saved some of the files, so bst wrote the recovery file to disk.
- Then you did some more development, possibly with compile / load cycles, but you saved all the tabs each time before you did it. In this case bst sees all files are saved and skips the recovery save.
- bst crashes and therefore leaves the recovery file behind, which due to the above sequence is multiple revisions out of date.
If this is what happened, then it's easy to prevent in the future. If not then there are possibly some ugly consequences for my autosave methods I'm going to have to figure out.
As a temporary fix, in the IDE preferences there is a check box that makes bst save all unsaved tabs before each compile, which means you can't forget to do it.
Now, as for the crash.. Are you using the latest release 0.19.3 or the latest 0.19.4-pre ?
Is your machine multi-core or does it have hyperthreading?
I'll borrow a windows box and see if I can reproduce the crash.
The popup is "Access Denied". But I think I may have solved it, at least I can't get a crash in the last half hour and that is not normal. There were 5 warnings at the bottom that I always ignored thinking that the compiler is correcting them:
ORG w/o value
JMP without #
JMP without #
JMP without #
JMP without #
FIT without value
ORG w/o value
So I put "0" for the ORG's, the compiler stated what the default was for FIT ($???) so I added that, then added the missing #.
T Chap. No idea what you are up to but be carfull about adding those # marks to jumps just to get rid of the warnings. Often they are intended to NOT be there. Like when you want to jump to an address conained within a LONG rather than the address of the LONG itself.
Good point. The JMP's are all located in the FDS4port. I will put them back in the JMP's and see if I get the crashes still. I did not test a la carte to see if there was one single offender.
Every time you compile a file, the editor packs all unsaved & modified tabs into a recovery file and stuffs them on the disk before it tries to compile. When bst restarts it checks for this file and if it finds it comes up with the "Recovering from a crash" message.
The recovery file is only removed on a clean close of bst.
Ok, so I've checked the code, and as far back as I can see, it has always removed the recovery file if all tabs were saved when you go to compile, so it's not that which caused your data loss.
Brad, last night I had 2 warnings for ORG without value and a FIT without value. I set those to the default values and have not had a crash since last night before adding the values, worked many hours today on BST. Normally I'd get many crashes a day. I did leave the warnings for JMP without #, since those may be intentional on the FDS4port. Seems really coincidental that it runs fine now. Thanks for looking into it, sorry it was probably related to the warnings.
Brad, last night I had 2 warnings for ORG without value and a FIT without value. I set those to the default values and have not had a crash since last night before adding the values, worked many hours today on BST. Normally I'd get many crashes a day. I did leave the warnings for JMP without #, since those may be intentional on the FDS4port. Seems really coincidental that it runs fine now. Thanks for looking into it, sorry it was probably related to the warnings.
No worries. I'll have a close look around the way warnings for those work to see if I can spot something odd. Very, very strange behaviour.
I have an FTDI TTL cable sitting on my desk in its anti-static bag courtesy of Tubular (Cheers!). I've not taken it out of its wrapper yet, nor looked at it more than sideways.
Additionally, my real CRO's are still in a box somewhere.
If that cable has RTS then it should be relatively easy.
Rest assured it's fairly high on the todo list.
'Are you suggesting coconuts migrate?'
Brad did you get to include this in the latest builds?
I have an FTDI cable which works under windows with PropTool but I can't get it to work with BST on my new Linux (Ubuntu 10.04) box ( it just may be that I am a Linux noob )
That is quite odd. Thanks for the pointer. I'll add it to my ever growing todo list.
(I had to look really, really hard at those quotes to figure out what was different!)
Brad did you get to include this in the latest builds?
I have an FTDI cable which works under windows with PropTool but I can't get it to work with BST on my new Linux (Ubuntu 10.04) box ( it just may be that I am a Linux noob )
Hrm. I missed this post, sorry Coley! I need to figure out how to re-enable E-mail subscriptions on this thread.
The answer is a definite maybe. I've got something basic working most of the time, but I need to break out the CRO and find out what I'm doing wrong. I'm also having a wee bit of trouble with RTS on the Mac. I'll get there, just having trouble finding time at the moment.
That is quite odd. Thanks for the pointer. I'll add it to my ever growing todo list.
Can you also add this one?
"Do not re-set the Prop when connecting the terminal".
Because when the terminal is on, since it resets each time it reconnects, you can't load the Prop Memory. You always have to load the EEPROM, which is taking way more time.
"Do not re-set the Prop when connecting the terminal".
Because when the terminal is on, since it resets each time it reconnects, you can't load the Prop Memory. You always have to load the EEPROM, which is taking way more time.
It does not reset the prop intentionally _ever_. Can you give me some more information about your system and the hardware you are using?
I've taken _great_ pains to even work around MacOS doing something with the DTR every time you open and close the port.
Hitting the disconnect/reconnect menu items in the terminal resets the Propeller.
I have not taken any notice as I have a habit to hit F11 all the time anyway.
Hardware is TriBlade Prop #2 and a Prop Plug.
Software is Debian Linux (Testing) and some recent BST version.
I'll have a play with it some more when I get home today.
Hitting the disconnect/reconnect menu items in the terminal resets the Propeller.
On both Linux and Win32 that's a bug. On OSX it's unavoidable. If you could pin it down to some easily reproducible behaviour I'll try and get it fixed.
I have this strange thing on XP pro. There are several objects. Today I needed to pull out a lot of code for a certain 'lite' version of the program. When commenting out a lot of code, I got a "fatal" compile error that consists of two lines, both referring to the idea that it can't find a certain object. So I start uncommenting and find a certain method in the main program that when commented out, gives the error, but when uncommented, will compile. It is weird since the same method gets use all over the place, and it is uncommented numerous times in the same block. Any thoughts on how this can happen?
I have this strange thing on XP pro. There are several objects. Today I needed to pull out a lot of code for a certain 'lite' version of the program. When commenting out a lot of code, I got a "fatal" compile error that consists of two lines, both referring to the idea that it can't find a certain object. So I start uncommenting and find a certain method in the main program that when commented out, gives the error, but when uncommented, will compile. It is weird since the same method gets use all over the place, and it is uncommented numerous times in the same block. Any thoughts on how this can happen?
Erum.. Something like :
"Fatal! Unable to locate object to fixup" ?
If so, then disable unused spin object removal. It's a bug. It's fixed in my local tree, but I've broken something deep inside the highlighter that is taking me a lot longer to fix than I'd like, therefore I've not released fixed builds yet.
If you attempt to compile and the bst reports an error (or some errors), then you click the error link, bst will open a new copy of the source (.pbas) file in a new tab - rather than show you the error in the source file already open.
This has led to me losing code between the 2 versions. Now I manually close the automatically opened tab once I have "seen" the error and instead edit in my original source.
Brad, on BST(c) there is an error that says "please report this bug"
"Bytecode of object exceeds size of memory"
This occurs after adding some code(spin). Prior to adding the code that gives the error, the compile says
Prog 7088 longs
Var 288
Stack/free 812
I have been having this happen lately. I have had programs compile that were much larger than this, and small code being added should not be pushing it over the limit. Remove unused, safe opti are both on. Without these it would have stopped compiling a long time ago due to size.
The problems seems to exist for adding different code, not just one specific instruction that I can track down.
Comments
Not sure how this happened, but on one crash last night, even after saving regularly, on reboot I get the message "we appear to be recovering from a crash", so it gave the option to resave using the same file name. I hit resave, but then realized too late that the program was definitely older than my last save. So I lost several hours, I can see that it is not a good idea to save over the same name as gets populated in the recover. The point being that I was wondering if it has already been discussed as to how to recover from some hidden file the latest file in a case like this?
XP Pro
Thanks
Wow. Well, that popup is a last resort error handler when things blow up badly (which appears to be happening in your case). That is not as distressing as finding the recovery save is not working properly for you.
Every time you compile a file, the editor packs all unsaved & modified tabs into a recovery file and stuffs them on the disk before it tries to compile. When bst restarts it checks for this file and if it finds it comes up with the "Recovering from a crash" message.
The recovery file is only removed on a clean close of bst.
Now, in your case I suspect what happened was this.
- You did a compile without having saved some of the files, so bst wrote the recovery file to disk.
- Then you did some more development, possibly with compile / load cycles, but you saved all the tabs each time before you did it. In this case bst sees all files are saved and skips the recovery save.
- bst crashes and therefore leaves the recovery file behind, which due to the above sequence is multiple revisions out of date.
If this is what happened, then it's easy to prevent in the future. If not then there are possibly some ugly consequences for my autosave methods I'm going to have to figure out.
As a temporary fix, in the IDE preferences there is a check box that makes bst save all unsaved tabs before each compile, which means you can't forget to do it.
Now, as for the crash.. Are you using the latest release 0.19.3 or the latest 0.19.4-pre ?
Is your machine multi-core or does it have hyperthreading?
I'll borrow a windows box and see if I can reproduce the crash.
ORG w/o value
JMP without #
JMP without #
JMP without #
JMP without #
FIT without value
ORG w/o value
So I put "0" for the ORG's, the compiler stated what the default was for FIT ($???) so I added that, then added the missing #.
So far so good. Thanks for the info on saving!
Hrm, and it only ever happened on downloading?
It sounds like bst is crashing while trying to access the serial port. I'll try to investigate further when I get the windows machine.
Ok, so I've checked the code, and as far back as I can see, it has always removed the recovery file if all tabs were saved when you go to compile, so it's not that which caused your data loss.
Sorry, I'll keep looking.
No worries. I'll have a close look around the way warnings for those work to see if I can spot something odd. Very, very strange behaviour.
Brad did you get to include this in the latest builds?
I have an FTDI cable which works under windows with PropTool but I can't get it to work with BST on my new Linux (Ubuntu 10.04) box ( it just may be that I am a Linux noob )
Regards,
Coley
I just found something strange on the Linux version.
Compile with no errors. When it should be:
I'm using BST version 0.19.4-PRE12.
JM
That is quite odd. Thanks for the pointer. I'll add it to my ever growing todo list.
(I had to look really, really hard at those quotes to figure out what was different!)
Hrm. I missed this post, sorry Coley! I need to figure out how to re-enable E-mail subscriptions on this thread.
The answer is a definite maybe. I've got something basic working most of the time, but I need to break out the CRO and find out what I'm doing wrong. I'm also having a wee bit of trouble with RTS on the Mac. I'll get there, just having trouble finding time at the moment.
Can you also add this one?
"Do not re-set the Prop when connecting the terminal".
Because when the terminal is on, since it resets each time it reconnects, you can't load the Prop Memory. You always have to load the EEPROM, which is taking way more time.
Thanks,
JM
It does not reset the prop intentionally _ever_. Can you give me some more information about your system and the hardware you are using?
I've taken _great_ pains to even work around MacOS doing something with the DTR every time you open and close the port.
Hi Brad,
I'm using this board:
http://www.parallax.com/Store/Microcontrollers/PropellerDevelopmentBoards/tabid/514/CategoryID/73/List/0/SortField/0/Level/a/ProductID/515/Default.aspx
With a standard USB -> Mini-USB cable.
My OS is Linux Debian in testing mode with Kernel 2.6.32.
I can provide you hardware details if required, and can run what ever test required.
Thanks,
JM
Hitting the disconnect/reconnect menu items in the terminal resets the Propeller.
I have not taken any notice as I have a habit to hit F11 all the time anyway.
Hardware is TriBlade Prop #2 and a Prop Plug.
Software is Debian Linux (Testing) and some recent BST version.
I'll have a play with it some more when I get home today.
On both Linux and Win32 that's a bug. On OSX it's unavoidable. If you could pin it down to some easily reproducible behaviour I'll try and get it fixed.
It's totaly reproducible. It's always doing that for me. I just have to press F10, and the Prop reset when it's loaded and start from the EEPROM.
If I disconnect the terminal, I don't have this issue.
So I'm now using a NTSC display as a console instead of the terminal to save some time between F10 and F11
I can do more tests if required, just let me know what I should try.
Thanks,
JM
Erum.. Something like :
"Fatal! Unable to locate object to fixup" ?
If so, then disable unused spin object removal. It's a bug. It's fixed in my local tree, but I've broken something deep inside the highlighter that is taking me a lot longer to fix than I'd like, therefore I've not released fixed builds yet.
YUP! Thanks..
Anyway, perhaps this feature is in there, but can I view the variable memory locations in some way, sort of like a microchip map file? or viewer?
(Using propbasic and bst.)
If you attempt to compile and the bst reports an error (or some errors), then you click the error link, bst will open a new copy of the source (.pbas) file in a new tab - rather than show you the error in the source file already open.
This has led to me losing code between the 2 versions. Now I manually close the automatically opened tab once I have "seen" the error and instead edit in my original source.
Made me mad because what my prop was doing was not was I had on the screen
So now I'm very careful and always look the tabs when BST open it automatically.^..
JM
"File/Increase font size" decrease it, and "File/Decrease font size" do nothing
So when you want to restore the terminal view, go to "File/Select font" and put a correct size.
JM
Here is the guilty code:
JM
"Bytecode of object exceeds size of memory"
This occurs after adding some code(spin). Prior to adding the code that gives the error, the compile says
Prog 7088 longs
Var 288
Stack/free 812
I have been having this happen lately. I have had programs compile that were much larger than this, and small code being added should not be pushing it over the limit. Remove unused, safe opti are both on. Without these it would have stopped compiling a long time ago due to size.
The problems seems to exist for adding different code, not just one specific instruction that I can track down.