 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 2 of 8   |
|||||
| Author | Message | ||||
twofingers Guru  Joined: 02/06/2014 Location: GermanyPosts: 1593 |
Hi MikeO Two questions: 1. Which MMbasic version? 2. Only the (Basic-)program was deleted? Michael causality ≠ correlation ≠ coincidence |
||||
| MikeO Senior Member  Joined: 11/09/2011 Location: AustraliaPosts: 275 |
Michael, I am fairly sure that the 170 was on 4.6. One occasion its was just the program but the last time it was mmbasic as well. To be honest I didn't try very hard to reproduce it at the time so i can't give you any more details I'm sorry. Codenquilts |
||||
| twofingers Guru Joined: 02/06/2014 Location: GermanyPosts: 1593 |
Hi MikeO, thanks! This helps! 
Michael causality ≠ correlation ≠ coincidence |
||||
| viscomjim Guru Joined: 08/01/2014 Location: United StatesPosts: 925 |
Can this have anything to do with the BOR or POR sections of the pic32. Can setting these differently make a difference? I am not sure but searching google for some ideas. This is a potential "big" problem. Still trying to figure out why I haven't lost mmbasic once but will alway loose my code when this happens. Starting to sweat a bit here.... |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4044 |
As I recall, 4.6 is NOT the fixed version. John |
||||
| viscomjim Guru Joined: 08/01/2014 Location: United StatesPosts: 925 |
So I tried to do a "controlled" experiment with this problem. Tried both 4.6 and 4.7. Used a clean 12v power supply and THIS voltage regulator. Used .1uf decoupling caps, with and without 100uf input and 100uf output caps on regulator. Using the same 5.5mm barrel jack and plug to make and break the power connection as this is how this project is powered. I was able to unplug and plug the power slowly and it didn't seem to lose the program anywhere near as much as when I did that quickly. Both firmware revisions acted the same and I never got the "MMBasic reset completed" message. The thing that makes this weird is that I never once lost mmbasic, only my program. No matter what I did to try and make this crash, mmbasic was alway intact. I only had to re upload my program with mmedit. So what is the difference between the memory that mmbasic resides in and where my program resides. Is there anything that can be done to the program memory to make it act like the mmbasic memory. I wish I knew more about this to ask the right questions. Any and all help is greatly appreciated as this is going to creep up on me. |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2944 |
Jim, Are you by any chance using MMEdit to upload your program? If you are, then there is a 'block' counter that increases in size as your program gets bigger. Is it worth experimenting with the size of program when this issue occurs? I seem to only experience it when powered by battery (with the 'debounce' effect) AND when the program is 'large' (i.e. size 200+ blocks in MMEdit). How big is your program? And are you powering by 'mains' or battery? I guess mains as you do mention barrel jack. If your program is small, can you copy/paste to make it bigger (i.e. above 200 blocks in MMEdit) and see if it then affects MMBasic. As per my earlier post, I was able to impact MMBasic in that it didn't respond to any console input; but it successfully displayed console output. Fully appreciate a supervisory helps with the situation, but why does it wipe code as opposed to MMBasic when there is a 'dirty' power connection?? Does code sit at the 'start' or the 'end' of the Flash memory (i.e. could this be a 'clue')? WW |
||||
| viscomjim Guru Joined: 08/01/2014 Location: United StatesPosts: 925 |
Hi WW, if you are talking about when I use the load and run running man icon, I get 153 "blocks" if thats what that is, not sure. The program is 19002 bytes when I use micromite chat to transfer the program. I will give this a whirl with a small program to see what the effect is. For this particular project, I don't have the option to use a supervisory chip as the boards are all done. (not a good situation to be in right now). I will report back... |
||||
| Chris Roper Senior Member Joined: 19/05/2015 Location: South AfricaPosts: 280 |
If you are at all familiar with MPLAB and C you could try creating a small C program for a blank device, one that just says "Hello I am alive!" on the serial port. Plug that in place of the micromite and repeat your tests. If it blanks out you know it is a hardware issue (possible Silicon error) if not it could be Micromite specific. Which device are you using? Cheers Chris http://caroper.blogspot.com/ |
||||
| viscomjim Guru Joined: 08/01/2014 Location: United StatesPosts: 925 |
Hi Chris, unfortunately, my C skills are non existent. I am using the pic32mx170f256b in a 28 pin SOIC package. |
||||
| Chris Roper Senior Member Joined: 19/05/2015 Location: South AfricaPosts: 280 |
Maybe someone on the list could knock up a test routine, we have a few C boffin's around. Unfortunately all my C stuff is for Chipkit and I don't have a Chipkit bootloader for the 170. I can do some testing and see if I can at least get the 150 bootloder to run on the 170, that way we could kill two birds with one stone by having a bootloader in the same spot that MMBasic is, to see if that survives an accidental erase. It may take a few days though as I have out of town clients to visit this week. Cheers Chris http://caroper.blogspot.com/ |
||||
| viscomjim Guru Joined: 08/01/2014 Location: United StatesPosts: 925 |
Chris, I appreciate greatly any ideas and tests you can do to try and narrow this down. Thanks!!! |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6283 |
XMODEM transfers in 128 byte blocks so 153 blocks is 153 X 128 = 19584 bytes. The last block can be full of nulls to pad it out. Using MM Chat to transfer is probably trimming leading spaces from each line which will account for the remaining difference in sizes. Block count is a good indication of the usefulness of any 'crunching' choices. Rather than simply adding comments to pad the file out. I would add a few extra functions etc to make the extra more 'genuine'. Jim VK7JH MMedit |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2442 |
you actually want to use a program that uses all of the flash (or as much as possible) in order to detect random corruptions no matter where in flash they may occur. a small 'i am alive' program will only be impacted by flash corruption in the area of flash occupied by the program. my suggestion is to have a small program that runs a check of the flash data (a checksum if you like), accompanied by a (compiled in) data object that consumes the rest of the flash - filled with some pattern of bytes such as 0x55 0xAA repeated. upon completion, the program should assert a given pin (with green LED attached) to indicate a 'pass', and assert different pin (with red LED attached) to indicate a 'fail'. the program should then repeat the check, ad infinitum. you then have three possible outcomes: 1. test program runs, flash OK 2. test program runs, flask corruption detected 3. test program fails to run. cheers, rob :-) |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2442 |
question: what happens if the Vcore capacitor is too high a value? i am wondering if maybe a high value of capacitor is able to maintain supply to the core through a brief dropout of Vcc? could those who have seen reset issues with 4.7 beta 23 perhaps post the value of the Vcore capacitor they are using? it would also be absolutely marvelous if someone could hook up a DSO with deep memory to Vcc and Vcore and record what the two voltages do when a brief power dropout occurs. cheers, rob :-) |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2944 |
10uF ceramic every time with me |
||||
| viscomjim Guru Joined: 08/01/2014 Location: United StatesPosts: 925 |
robert.rozee, I am using a 22uf X5R ceramic on this unit. I will try a few other values to see if there is a difference. I am running 4.7 also. |
||||
| viscomjim Guru Joined: 08/01/2014 Location: United StatesPosts: 925 |
So I just tried a 10uf x5r ceramic and got the same results. No program, but mmbasic is still there fully functional. Going to try a 47uf tantalum next. Just to rule out a particular 170, I am trying this with 3 different 28 pin uMites. Keeping fingers crossed.... White Wizard, have you had any experience with the 44 pin doing this? I don't have a 44 pin 170, but I do still have a 44 pin 150 I can try. |
||||
| twofingers Guru Joined: 02/06/2014 Location: GermanyPosts: 1593 |
I thought this issue never occurred with the MX150 (and MMBasic <=4.5)!? causality ≠ correlation ≠ coincidence |
||||
| viscomjim Guru Joined: 08/01/2014 Location: United StatesPosts: 925 |
That is quite possible and now that I think of it, I never ran into this problem with the 150. I might just do a quick setup and swap in a 150 just to see. |
||||
| Page 2 of 8 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
