 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : how to "reset" a Maximite ?
  Page 2 of 2 |
|||||
| Author | Message | ||||
BobD Guru  Joined: 07/12/2011 Location: AustraliaPosts: 935 |
Good find. The V3.2 manual explicitly notes this while the V4.x manual says that any invalid memory address accessed will reset the processor and clear memory. |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3167 |
The interpreter should catch any "bad code" and simply give an error message. As Gizmo said, you can force a reset with POKE 0,0,0 (which is the one exception to the above) but that is like kicking it in the head - the PIC32 will crash and restart and there will be nothing to indicate what happened. Geoff Geoff Graham - http://geoffg.net |
||||
| TinkersALot Regular Member  Joined: 20/11/2012 Location: United StatesPosts: 72 |
Thanks everyone for all the Information! |
||||
| Talbit Senior Member  Joined: 07/06/2011 Location: AustraliaPosts: 210 |
Gents I have a situation where with some conditions with my GPS clock (see my posts) my MM produces an error and terminates the program. I remember a hundred years ago running BASIC on a PDP11 there was an instruction "On Error GOTO ..." So if something disastrous occurred you could loop out, fix the problem - or log the issue - and continue on Is there such an instruction in MM BASIC so that I could go back to the start if an error occurs? Start: Do Some code... Subroutine containing some code and "On Error GOTO Start" More Code... Loop Yes, I know I should fix the problem in the program but if I can't fix the bug in software then I thought a hardware watchdog timer might be the best thing to cover all the bases. Regards Talbit Talbit |
||||
bigmik Guru Joined: 20/06/2011 Location: AustraliaPosts: 2870 |
I know you will not believe this I was just now going to pose the same suggestion, it can be very good for not only catching those pesky once in a blue moon bugs but to help debugging.. Regards, Mick Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
| Talbit Senior Member Joined: 07/06/2011 Location: AustraliaPosts: 210 |
Thanks Mick, Now that I've thought more about the PDP11 BASIC, I don't think it actually continued if it really crashed. It was an error routine which for instance looked at the user response to a question. If the input was something completely random and crazy then that was considered to be a USER INPUT error and on that error it would go to a routine and tell you "No, stupid - I said I wanted a number, not a letter" or something like that. We thought we were really clever because we could write what we liked! I'm trying to fix this problem with my clock and I'm including a whole series of breaks to find out what happens when this particular error causes the MM to crash. Whatever - it keep me away from the tellie!!! I thought I had the clock running perfectly. I was comparing it to a TrueTime GPS clock, considered to be a very stable and accurate clock. I was demonstrating to my colleagues as to how clever I was when a mate (god bless him) unplugged the GPS NMEA cable from my MM clock - this could easily happen in real life. When we plugged it back in the display read exactly 1 second behind the TrueTime. Talk about sole destroying! If I reset the MM then that got it all going in sync again. Hence the need for a reset system be it a watchdog timer or a very reliable software reboot. But I'm working on it. Talbit Talbit |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3167 |
"On Error GoTo" done the Microsoft way is a tricky thing to get right and it can cause some strange errors. When I was designing MMBasic I thought about this and figured that it was best for the interpreter to just throw an error and stop if it hit a programming error (like syntax, no such command, etc). After all, what is the point of trying to recover from that? If you have a serious error you cannot recover, it needs editing. The situation where it would be useful to recover is when dealing with files on the SD card. For example, if the file could not be found you would like to recover and prompt the user to insert the correct card. So this is why we have ON ERROR CONTINUE. I suppose that there is a third type of error like divide by zero where it would be handy to recover. But (says he scratching his head) that is the only one I can think of right now. Can anyone think of others? (it must not be only fixable by editing the program for then it would fall into the first category). Geoff Geoff Graham - http://geoffg.net |
||||
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
In my early 'career' basic was the language i used for many programs, many of them were used in an administrative or other environment that does not allow programs to just stop. Of the different kinds of error trapping that basic used i found the ON ERROR RESUME NEXT offered the easiest and most robust way. The places i used it the most were with file access, like opening a file for read when the file not exists, or a write to a file that is read-only etc. Another use was with the comm ports, they timed out, had invalid characters, full buffers etc all of which could throw an error. Converting strings or parsing strings can throw errors when one of the parameters for functions is out of range like print mid$("Hallo",10,5). Calculations can have overflows or divide by zero. There was an error variable that holds the code, message and linenumber were the error occured. With those you could determine what kind of error it was and if the program was able to recover from it without user intervention. Also usefull for informing the user what went wrong while still staying within the program. In a microcontroller environment many things can throw an error, like in another post that the can bus could not be enabled, Or when a pin is defined for input and you try to output something etc. Syntax error are often fixed quickly, runtime errors are the ones that can stop a program from continuing and that is often a real problem. Having a way to recover or retry is very useful especially when something is made and it ends up in a box without a screen or keyboard. Microblocks. Build with logic. |
||||
gconlon Newbie  Joined: 07/09/2011 Location: Posts: 2 |
Would another be an invalid array dimension, e.g. trying to access array(0), when your base is set to 1. Cheers, Greg |
||||
Juri74 Senior Member Joined: 06/02/2012 Location: ItalyPosts: 162 |
that's very simple in color maximite: type 0 (zero) and hit enter, if there is something in memory type NEW first  |
||||
CircuitGizmos Guru Joined: 08/09/2011 Location: United StatesPosts: 1421 |
I don't think that is intentional. I would guess that it is a bug. Micromites and Maximites! - Beginning Maximite |
||||
| bigmik Guru Joined: 20/06/2011 Location: AustraliaPosts: 2870 |
Unfortunately you cant do it under program control (or even if there is a program in memory) Like Rob, I think its a bug. Regards, Mick Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
| CircuitGizmos Guru Joined: 08/09/2011 Location: United StatesPosts: 1421 |
I think if RESET (as a command) were to be done, it would have to disconnect the USB stack, pause for perhaps 5 seconds, and then continue. When a Maximite is reset (hardware switch) too quickly, Windows cannot keep up with the USB device going away and coming back quickly (which happens when you punch the reset button) without the USB connection going south. Micromites and Maximites! - Beginning Maximite |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3167 |
I still cannot figure out why someone would want to force a reset while a program is running. But, if you want to do it, it is as simple as connecting an I/O pin (say, pin 20) to pin 1 of the ISCP connector and placing this command in your code: SETPIN 20, 8
Geoff Geoff Graham - http://geoffg.net |
||||
| Page 2 of 2 |
|||||
 Print this page |
