 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 5 of 8   |
|||||
| Author | Message | ||||
Geoffg Guru  Joined: 06/06/2011 Location: AustraliaPosts: 3292 |
Interesting thread - I missed following it while I was away. I am still a little confused. Ver 4.5E has essentially the same initialisation code as the 4.7 Beta (ie, detect if baudrate is erased and if so, set the initial defaults). So, both versions should act the same. Also Ver 4.5E has the old method of resetting (short Tx and Rx) and was much more sensitive to power glitches on startup and subsequently erasing its program. Anyway, setting the defaults on initial startup has caused problems in other areas so I will look at initialising them in the hex file. Hopefully in the next beta. Thanks for the detective work folks. Finding the bug is the hard part, fixing it is nearly always the easy part. Geoff Geoff Graham - http://geoffg.net |
||||
| viscomjim Guru Joined: 08/01/2014 Location: United StatesPosts: 925 |
Hi Geoff, first of all, welcome back! (I'm assuming you're back?) This one has been interesting. If you are interested, I could probably shoot a video of this with both firmwares and how they react to the power glitches. But I can definitely tell you that I cannot get 4.5E to fail at all compared to 4.7, with this power thing. Instead of changing my program to work completely with 4.5E, I will wait till you take a look at this as some of the features that 4.7 has over 4.5 are worth the wait. I hope you had a great time on your vacation!!! |
||||
twofingers Guru Joined: 02/06/2014 Location: GermanyPosts: 1593 |
This are good news for us micromiters. 
Maybe we can have a 4.5E for the MX170 please (and a way to get the source code). Just in case and if it's easy to do. I didn't realize that the 4.5D is so limited. Regards Michael causality ≠ correlation ≠ coincidence |
||||
| twofingers Guru Joined: 02/06/2014 Location: GermanyPosts: 1593 |
Hi Jim, do you have any results with the "delayed startup" (the R/C circuit)? I'd do it myself, but I can not reproduce the error. 
Michael EDIT I experienced the problem only twice. causality ≠ correlation ≠ coincidence |
||||
| viscomjim Guru Joined: 08/01/2014 Location: United StatesPosts: 925 |
Hi twofingers, I didn't try the rc delayed startup at this point as I needed to find a solution without changing hardware. I already had 200 (using a 170) boards made with 10k on pin one to vcc, and don't have the option to change this design, thats why I was panicking to try and find why this was happening in this firmware revision and not on anything I ever made with the 150. I did try different Vcaps, 10uf, 22uf, and 47uf and they all worked the same. Just for good design sake, I think in the future, I will use an MCP130 supervisor in any larger projects that will go out to customers. This one allows you to still use the ICSP. But, still, I can't get the 4.5E to fail, no matter what I do to it, so that's a good sign also. |
||||
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
I have used MCP120T-315I/TT and MCP120T-450I/TT with success. The 130 versions have an internal pullup resistor which makes it possible to remove the resistor from your pcb and replace it with the supervisory chip with only one extra connection to ground. This might be a way to add it to an existing pcb layout. You can even choose between 3 different TO-92 packages to get the best fit. Microblocks. Build with logic. |
||||
| twofingers Guru Joined: 02/06/2014 Location: GermanyPosts: 1593 |
Hmm, it's up to you but I can't see any advantage. Maybe I'm to "spartan minded". 
I think it is of general interest if the RC circuit (or the MCP130 for the reset) the erasing prevented. So far we have only theory. It would be better to have facts. EDIT: Seems we have some facts for MCP130. causality ≠ correlation ≠ coincidence |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
An RC circuit will not prevent the mcu from executing wrong code. In a brownout situation memory read/writes and thus instructions can be corrupted. It is very important that a mcu is in a known state. A supervisory chip helps with that. It takes less room on a pcb then a resistor and cap. The price is also low. I recommend to always use one. Only reason not to is when the mcu is running some simple and innocent program. The MMBasic interpreter is very complex and uses a lot of internal administration. One bit wrong and it will do something unexpected. Different every time, it might feel like a bug, but first the need is to prevent errors in hardware. Microblocks. Build with logic. |
||||
| twofingers Guru Joined: 02/06/2014 Location: GermanyPosts: 1593 |
I would suggest we should distinguish. The "erase issue" seems only occur since v4.6. I never heard before V4.6 of some sensibilities of micromites (after the start up). AFAIK makes a MCP130 only sense if you activate the Watchdog function? There are some power supplies conceivable that make a voltage drop situation very unlikely. The startup is the most critical moment. causality ≠ correlation ≠ coincidence |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
The erase issue was already present in the first uMite. First, the software must never ever write to flash when starting up. In Geoff's code there was a test to see if a memory location was filled with a certain number. The code is not faulty. The mcu was because of power conditions. A brownout can occur for many reasons. A capacitor could fail, a resistor overheats, a wire breaks, etc. You would not want the code to run under those conditions. Can not prevent everything, but the more the better. If your power supplies fails and gets repaired, it would be very unfortunate if the mcu ran some code by accident that erased some of the flash. Especially when it is at a customers place, maybe build into some structure. Or in a dashboard from a car, which seems a place that a lot of uMites can be used. Cars are known for their bad power conditions. Microblocks. Build with logic. |
||||
| twofingers Guru Joined: 02/06/2014 Location: GermanyPosts: 1593 |
I did not know that. Is there a link? That's true! causality ≠ correlation ≠ coincidence |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
http://www.thebackshed.com/forum/forum_posts.asp?TID=6512&KW=TZAdvantage Microblocks. Build with logic. |
||||
| twofingers Guru Joined: 02/06/2014 Location: GermanyPosts: 1593 |
Thanks TZA! Seems you made a lot of testing already in the past! 
I should read this thead earlier. I think now I'm myself able to do more tests on this issue. This referred to version 4.5B ? causality ≠ correlation ≠ coincidence |
||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9610 |
Yes, indeed. My favourite is the 130-315 flavour of that chip(cos it has an internal pull-up, so no need for an external one), in SOT23 package - it is tiny, and as you said in a later post, even smaller then any resistor/cap arrangement would be. The 13-315 costs all of 76c in New Zealand money, which is only 48c in the greenback - these are Element14's prices, but Microchip Direct would probably be even cheaper - their page would not load for me for some reason. Smoke makes things work. When the smoke gets out, it stops! |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2944 |
Not sure if this may help Geoff: With v4.7 B23 on a 28pin MX170 running on a battery I often experience the issue with a rapidly 'bounced' power connection (no supervisory chip); i.e. the program gets wiped but MMBasic mainly stays in tact. However, just now I had my (large) program still in tact BUT got an error message "Error: Flash write" when I ran my program. The line highlighted with the error was the simple statement "OPTION AUTORUN ON". Note this is the fourth line of my program; the previous three lines being: CPU 48 OPTION EXPLICIT OPTION DEFAULT INTEGER So does this mean that on this occasion the Flash got corrupted, or that MMBasic did??. I can confirm that all my code was in tact (and is a known working program). The only way out was to reflash the firmware (as expected) Maybe a valuable 'clue' for Geoff? . . . 
EDIT: I do not need to fix this from a hardware point of view so please don't reply saying I need to add a supervisory chip!! |
||||
| viscomjim Guru Joined: 08/01/2014 Location: United StatesPosts: 925 |
Hi WhiteWizzard, since you have this setup and you now know how to make it fail, are you in any position to load your setup with 4.5E and do exactly the same thing to see if it falls over or not? I am in the same position as I actually can't do any hardware changes. I had to make a few changes in my program for it to work under 4.5E and I am using almost all of the memory, however, I CAN NOT get this to fail, no matter how brutal I am applying power. Maybe you can do just a quick small new program to see. |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2944 |
Hi Jim, Unfortunately the program I use has features that are only available in v4.6. I don't really want to load a different program as all the I/O pins are connected to things that involve high-current power-management control. One incorrectly set pin could be disastrous for my hardware setup. What I can do is set up a 28-pin MX150 MuP with 4.5E and feed it from the same LiPo battery (this should be possible to make fail with v4.6 first). Only thing now is that it will have to wait a few hours till this evening (UK - currently 1pm). Standby - I know how important it is for you to resolve . . . .
WW |
||||
| viscomjim Guru Joined: 08/01/2014 Location: United StatesPosts: 925 |
Thank you kind sir. Right now I am running 4.5E on the 170 and I modified my program to deal with the missing coolness features like shift, which i did x\2 or x*2, thats to the power of two, just don't know how to type it here, and end if = endif, etc. So everything is working for now and my client is non the wiser. I am just at the very limits of the memory, but with the help of mmedit, I gained some back. Have a great day!!! |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2944 |
Jim, Did you want me to test your exact code here? I can assure you of complete confidentiality and non-disclosure of your code - your call. I take it that it be better that I test on a MX170 then? |
||||
| viscomjim Guru Joined: 08/01/2014 Location: United StatesPosts: 925 |
I appreciate the offer and will get everything together when I get out of work today. Yes, 170 (28 pin) running 4.5E. |
||||
| Page 5 of 8 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
