 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 : weird loss of program issue
Page 1 of 8   |
|||||
| Author | Message | ||||
| viscomjim Guru  Joined: 08/01/2014 Location: United StatesPosts: 925 |
Hi All, I have come across a strange issue with loosing my program code. I am running 4.6b on a 28 pin uMite. I send my program to it using MMedit as usual and all is great. Program runs just fine so no problem there. I have a 3.3v regulator on the unit with filter caps and am powering the regulator with a standard wall wart at 9vdc. I am using 5.5mm barrel jack and plug and disconnect the two to remove power from the board. I am also using option autorun on. Sometimes I have to use one hand to connect the plug and jack as the other hand is holding down a switch or something. When I do that, it gets a bit tricky to make the connection and I am sure that I am literally turning the unit on and off several times very quickly as I fumble to get the plug into the jack with one hand. I noticed that on more than one occasion, when I connect the power using this fumble method, the uMite will power up and the Geoff welcome string will pop up on the screen, but the program is not auto starting. So I do a "list" and there is nothing there. My program is gone. So I simply reload the program and all is fine. But this does happen, just not consistently. My pin 1 is tied high using a 10k resistor. I guess my question is, if the power is coming in really flakey, maybe it turns on and off several times quickly, (this is the only time I loose my program) until I actually get the connectors put together right, can this cause the program to actually get wiped out? When the program is loaded to the uMite using MMedit, doesn't it get stored in flash just like the MMbasic does? If so, why does the MMbasic never get lost. It is always there, just my program disappears. Does it make a difference if I load MMbasic and then my program, read it all back out with the picket 3 in hex and reload the whole shooting match with the picket instead of using mmedit? I have tried this with several different uMite setups and they all do the same thing. Again, not consistently, but it does happen and it is freaking me out. Thanks for any and all input. EDIT... Is there a "bit" that can be switched on or off to prevent reading or altering the memory, so for instance, I load the program and read everything out using IPE and then reload the hex (mmbasic and my program) with a setting to not allow any alteration or something of that nature? |
||||
| PicFan Senior Member  Joined: 18/03/2014 Location: AustriaPosts: 133 |
Hello ! This is a known problem in V4.6, but with Version 4.7B23 the problem is solved. |
||||
| viscomjim Guru Joined: 08/01/2014 Location: United StatesPosts: 925 |
Holy cow thats good news. I will have to try 4.7b23. Is there any info or thread related to this problem that I can look at, that you know of? |
||||
twofingers Guru Joined: 02/06/2014 Location: GermanyPosts: 1593 |
http://www.thebackshed.com/forum/forum_posts.asp?TID=7520&KW Regards Michael causality ≠ correlation ≠ coincidence |
||||
| viscomjim Guru Joined: 08/01/2014 Location: United StatesPosts: 925 |
Thanks twofingers, that is exactly my problem. Switching to 4.7 now.... |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2944 |
I hate to say it, but I have experienced this issue several times now with 4.7B23 on a MX170. 
I have raised it with Geoff (at the time it had only happened twice to me), but in the last week it has happened four more times in 'general' use when I wouldn't expect it to happen. As viscomjim mentions in his original post, it is very strange that the user program gets wiped from flash, but not the firmware. Geoff was also puzzled as to how this can happen i.e. why does only the user code get wiped 
The setup in which this is happening for me involves a battery powered MX170 with a 10uF vCap (and plenty of decoupling caps in place). I can randomly re-create the issue if I do a 'dirty' power connection, as in effectively apply power and disconnect power very quickly several times (similar thing to switch input bounce in a micro-controller circuit). This is a common thing to what viscomjim mentions. @Geoff: On three occasions I noticed that when I monitored what was happening with my (OLED power management) circuit on TeraTerm, I could see the 'MicroMite....' startup message (as expected) indicating that MM Tx is fine, and also saw the flashing cursor, but I could not see anything that I was typing (as if the MM Rx input was disconnected). On these occasions my program had been wiped. However, as soon as I re-flashed the firmware, everything was working again (confirming it was not a 'faulty MM Rx connection). Are these possible examples that part of the firmware does also get wiped?? With the circuit I have it is also possible to supply power via a mains driven power-pack. I have NEVER had an issue with the program being wiped whenever the circuit is powered by this. BUT note the battery then 'kicks' in anyway so there is never a case of 'dirty' power connection when it comes to the power-pack  |
||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9610 |
Perhaps it would be wise to make standard use of a supervisory chip such as the MCP130, as I have used on a couple of my boards - but not all of them. They do add a buck or so to the overall cost, but it could perhaps be cheap insurance? These supervisory chips will hold the device in reset till the PSU settles down, ruling out any such jitter-related issues. I thought that the exclamation mark method was pretty bulletproof..... Smoke makes things work. When the smoke gets out, it stops! |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2944 |
Thankfully for my circuit the battery is going to always be connected. It is just during testing that I need to connect/reconnect the LiPo to avoid any nasty shorts whilst soldering. Just annoying when you reconnect the battery that the code sometimes disappears. If I get time I was going to drop in a supervisory chip to see if I could then make it 'fail'. Will post results if I get around to that test . . . . WW |
||||
| Greg Fordyce Senior Member Joined: 16/09/2011 Location: United KingdomPosts: 153 |
Has anyone tried using the delayed start up circuit shown on page 30 of the uM user manual 4.7 beta? Maybe this would help in these cases. |
||||
| viscomjim Guru Joined: 08/01/2014 Location: United StatesPosts: 925 |
Well, I tried the 4.7 and although it took a while, I did manage to wipe out my program. What is weird is that MMbasic stays intact. What is the difference between the memory that mmbasic is occupying vs where my program is? Maybe this is a key to success. I would hate to have to use a supervisory circuit or even add a reset circuit with the cap as I have quite a few boards made with out this facility. Going back in history, I made quite a few battery operated circuits using the 150 and never came across this situation. I can only hope that this is a "minor" thing that can be fixed. I am still wondering if there is a special bit or something that can be set or reset that will not allow a change in memory once programmed. This would solve any issue in a "production" situation. KEEPING FINGERS CROSSED... ON BOTH HANDS RIGHT NOW. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4044 |
It still happens with the changed MMBasic? I thought the change had fixed the problem. John |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2442 |
1. as long as the code to erase the stored basic program exists somewhere (anywhere) in flash, there is the possibility of a random glitch at some time causing a jump to it. unfortunately it is just about impossible to protect against this sort of event, although in the present case i suspect this is not what is happening. 2. in an entirely different scenario, if MMbasic is sitting there for 100mS at startup 'just waiting' for the cue to jump to the factory reset code, then there is a chance that a glitch could cause the processor to 'jump the gate'. one way of countering this is to have a magic keyword that must be stored in RAM, that the reset code checks right before it initiates the erase sequence, bailing out at multiple points if the keyword is missing. for instance, the user entering "!!!!!!!!!!!!!!!!!!!!!" as already required, then MMbasic prompts the user to type in a letter sequence like "RESET". as the user types them store the sequence of letters at a fixed location in RAM, then jump to the factory reset verify code when enter is pressed. just before calling the flash erase commands, the factory reset verify code then looks in RAM and checks one-by-one (not using a loop, coded with multiple exit points) that the letters "RESET" are stored in RAM correctly: push address of erase_proc onto stack
if keycode[1] <> 'R' jump reboot_vector if keycode[2] <> 'E' jump reboot_vector if keycode[3] <> 'S' jump reboot_vector if keycode[4] <> 'E' jump reboot_vector if keycode[5] <> 'T' jump reboot_vector execute a return instruction the above example requires the first line to be executed to set up the address to be called. the last line then does the actual jump into the erase procedure. both events are necessary, hence ensuring the 5 checks in the middle are also performed and pass. cheers, rob :-) |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3292 |
A couple of things here. Firstly, I believe (99.9% confident) that the current reset system with exclamation marks is bullet proof - for a start it requires that the power must be stable for a couple of seconds which is not the case in your tests. Secondly, if it does kick in it will only erase program memory and reset the options to their defaults. It cannot corrupt MMBasic. If you have accidentally triggered a reset you will get the message "MMBasic reset completed". No message, no reset. This indicates that the flash used by MMBasic has been corrupted by a hardware issue (not a MMBasic reset) - this is why you needed to reflash. MMBasic cannot prevent this so I agree with Grogs that you need something to hold the chip in reset until the power has settled. Geoff Geoff Graham - http://geoffg.net |
||||
| twofingers Guru Joined: 02/06/2014 Location: GermanyPosts: 1593 |
Hi Geoff, Do you think a "Delayed Start Up" (as described in the MMBasic manual) will do the same? Regards Michael causality ≠ correlation ≠ coincidence |
||||
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
A delay start will not suffice. There are lots of brownout situations that possibly can cause the same. A supervisory chip takes care of that too. Although i never had any PIC (non MM) ever erase its flash by a faulty or dirty power up. Microblocks. Build with logic. |
||||
| Greg Fordyce Senior Member Joined: 16/09/2011 Location: United KingdomPosts: 153 |
While I understand that a supervisory chip would be the gold standard solution, I still can't understand why using the delayed start wouldn't help with this particular problem. The only way to know would be to try and see if the delayed start circuit helps in this particular case. |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3292 |
Yes, something like that would work for WW's particular problem although you would need to add a diode to quickly discharge the capacitor when the power momentarily failed. There are many ways that the power can cause issues and many solutions. A supervisor chip is one of the better solutions. Geoff Geoff Graham - http://geoffg.net |
||||
| viscomjim Guru Joined: 08/01/2014 Location: United StatesPosts: 925 |
Why is it that the MMbasic stays intact when the program disappears? Isn't it in the same type of memory or am I mistaken here. |
||||
| twofingers Guru Joined: 02/06/2014 Location: GermanyPosts: 1593 |
A schottky diode? In this way? 
(Note: Image mainly from Micromite MMBasic Ver 4.7 Beta Manual) Michael causality ≠ correlation ≠ coincidence |
||||
| MikeO Senior Member Joined: 11/09/2011 Location: AustraliaPosts: 275 |
Another sugestion, I have a battery driven project using a 170. Power supply is from 2x NiMh AA batteries via a 3.3 v Buck Boost module like this . I have changed the batteries many, many times and have never had any issues, so it seems to be a very reliable system however I have another 170 collecting weather data powered from a 12volt battery supply via a linear reg which has on a couple of occasions wiped the program on power loss. Codenquilts |
||||
| Page 1 of 8 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
