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.
WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2944
Posted: 03:12am 05 Sep 2015
Copy link to clipboard
Print this post
Changed my plans to allow me time to run a few tests straight away.
Just got a 28pinner MX170 with v4.7 B23 on a MuP powered externally from a battery. Console connected to TeraTerm to observe test AUTORUN code. This is my 'test' set-up to ensure I get wiped code whenever I 'bounce' the battery power input.
Am using MMEdit to download code. In the following, I refer to 'block size' in which I mean the second of the two numbers shown by MMEdit when downloading a program.
Major observation: With my program that suffers from being wiped, it is 273 blocks in size. Got this to be wiped pretty much immediately on the above setup.
However, with a small program (my standard 'Welcome' message I pre-load on customer's MM(+)s, which is only 8 blocks in size, I just cannot get it to wipe itself.
So early indications look as if program size is a deciding factor as to whether the program gets wiped.
Will now load 4.5E and see what happens to the 273 block size program.
Standby . . . .
Edited by WhiteWizzard 2015-09-06
WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2944
Posted: 03:44am 05 Sep 2015
Copy link to clipboard
Print this post
With v4.5E loaded I was limited to a maximum of 159 blocks (otherwise a 'Transfer Error' occurred.
Had to use a different program as my 273block program had too many 'new commands' that obviously weren't recognised in v4.5E.
So with a 159block program (which reported back as 97% flash used out of 20K) I just could not get the code to 'wipe'. The small 8-block program was once again impossible to wipe.
Will now try various programs in v4.7 B23 that are bigger than 159 blocks but less than 273. Will see if it appears to be a 'size' issue.
Has anyone had a 'small' program on a battery powered MicroMite get wiped mysteriously?? If so, can you send me the code so I can test here if that's ok! Thanks
WW
viscomjim Guru Joined: 08/01/2014 Location: United StatesPosts: 925
Posted: 03:51am 05 Sep 2015
Copy link to clipboard
Print this post
Hi WhiteWizzard, on my setup with 4.7b23 it didn't matter how big or small my program was. I wrote a small flash the leds program with option autorun on so that I could fiddle with the power and instantly see if my leds were not flashing that the program was gone. Did the same with 4.5E, no problems, small or large program.
Just my 2 cents...
WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2944
Posted: 04:20am 05 Sep 2015
Copy link to clipboard
Print this post
MAJOR BREAKTHROUGH:
As Jim says, "size doesn't matter"!!
BUT (and you touched on it), with a line of code OPTION AUTORUN ON near the start of a program (which I presume writes to flash), I can repeatedly get the program to wipe on v4.7. But comment the line out and it just won't wipe.
Have not tried with v4.5E but as Jim says, he has no problem. I will try this next (just have to find my PicKit3 which has just vanished!).
JIM: Try your code on v4.7 but comment out OPTION AUTORUN ON (I bet it will work!). If it does fail, then are you using any other commands that 'talk' to FLASH? If so then comment these out too . . . .
I think we are close to giving Geoff something to go on . . . .
WW
EDIT: it is much as TZAdvantage has said - must not write to Flash at startup (i.e. during 'bounce')Edited by WhiteWizzard 2015-09-06
Chris Roper Senior Member Joined: 19/05/2015 Location: South AfricaPosts: 280
Posted: 04:38am 05 Sep 2015
Copy link to clipboard
Print this post
Sounds like your desk is as bad as mine I find that tracing the USB cable back from the PC to the Device works most times.
Good catch on the Autorun Option.
Cheers
ChrisEdited by Chris Roper 2015-09-06http://caroper.blogspot.com/
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209
Posted: 05:00am 05 Sep 2015
Copy link to clipboard
Print this post
I do not have a product that goes out to customers that has a MM so take this as theoretical. (I have some PICs (1500) out there that send GPS positions from vehicles that use external flash memory for log storage)
What I would NEVER do in a product is write information to the internal flash that can stop the program from working. All defaults should be used either as DATA or constants in a program.
Second if information is written to flash it MUST contain at least a checksum or other means to detect wrong values. This will allow the program to determine what should be done. If saving values is critical use two areas in flash and verify after write. If that fails use the other area. If during a flash programming step the power fails at least one area should still be ok. But even that in worst case could fail hence the default as a fall back.
In the case of a uMite there is code in the firmware that does things at startup.
This part can only be changed by Geoff, or you need to modify it yourself.
Until then there is a continued risk that your PIC gets bricked or program gets lost. Even if you test it a thousand times, a few of your customers will experience this problem.
The question for you Viscomjim is, while knowing this, do you take that risk or not.
I think the risk with 4.5D after your tests is small, but the problem is not really gone. Even with a supervisory chip the risk is still there as power could be removed while a flash write is busy.
Edited by TZAdvantage 2015-09-06Microblocks. Build with logic.
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209
Posted: 05:08am 05 Sep 2015
Copy link to clipboard
Print this post
@WW,
The OPTION AUTORUN ON should at this moment not be a part of your program.
It writes to flash and as such will involve some risk that that fails.
If i read the manual right the OPTION AUTORUN ON can be done at the prompt before saving your program.
Even edits will not change it.
This might even need Geoff's attention as including the OPTION AUTORUN ON is very convenient to include in the program.
If a test can be done if the option is already set then the write to flash can be skipped. This will be good for other OPTIONS too.
This remark is only valid if indeed a flash write occurs after setting the OPTION more than once with the same value.
Microblocks. Build with logic.
WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2944
Posted: 05:09am 05 Sep 2015
Copy link to clipboard
Print this post
One thing I am still a little puzzled by is this: Why does this problem show itself much more with 'battery powered' MMs over USB/PSU powered MMs.
The obvious thing is that there are caps in a PSU; but then we add caps to the MM power rails so surely this is the same thing and hence should be fine for a battery power source?
I have to go out now (and still lost my PicKit3). When I come back I will try the OPTION AUTORUN ON with other firmware versions to see if there is a 'pattern' we can highlight to Geoff.
If indeed v4.5E is not affected anywhere near as much as v4.7 then there has to be a 'clue' there to minimise this effect. At the end of the day nothing is really 100% bullet proof; you simply have to strive for what is considered acceptable. For an end product that is battery powered, then loosing 'code' every time a battery is replaced is not really any use to anyone. However, if there is a potential software solution to make this only occur one in a hundred times then this 'may' be acceptable.
One thing I will try later is to add something like a 'pause 1000' at the very start of my 'test' program to delay the OPTION AUTORUN ON. This may be something that helps for now possibly . . .
WW
WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2944
Posted: 05:13am 05 Sep 2015
Copy link to clipboard
Print this post
I never use to do this, but then one day I saw it in someones code here on TBS and thought it a great idea to include.
Totally agree with you regarding FLASH writing at 'start-up'.
Over to Geoff now . . . .
robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2442
Posted: 05:16am 05 Sep 2015
Copy link to clipboard
Print this post
just an interesting observation: strictly speaking, "OPTION AUTORUN ON", although it can be placed within your code, really shouldn't be placed there - the command should be issued ONCE at the command prompt.
but in practice, most folks place it in code, so that when the code is first run (manually) the option then becomes set. this is much easier, and means that in a production environment there is one less step to carry out.
might i suggest that mmbasic should be checking the current state of autorun, and only processing the command if autorun is currently off. this rule should hold true for all persistent option commands, a write to flash should only happen if the value in flash differs from the value that is being set.
currently, would the following code eventually wreck a micromite if left running?
OPTION AUTORUN ON
PRINT "hello world"
CPU RESTART
addendum: once again, my slow writing sees my posting 'out of date' before i click the 'post reply' button!
cheers,
rob :-)Edited by robert.rozee 2015-09-06
twofingers Guru Joined: 02/06/2014 Location: GermanyPosts: 1593
Posted: 05:30am 05 Sep 2015
Copy link to clipboard
Print this post
Good point!
@WW
Good job, finding that it depends on the size (and OPTION AUTORUN too).
Maybe the explanation why this bug is so hard to find.
I was always wondering about users who implemented the OPTION AUTORUN ON in their code.
@rob
Good point too (AUTORUN needs to check if it's already ON)!
MIchaelcausality ≠ correlation ≠ coincidence
WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2944
Posted: 05:37am 05 Sep 2015
Copy link to clipboard
Print this post
NO - size does NOT matter (no matter what women say!!)
Purely writing to flash during any power 'bounce' is my conclusion as to what is causing a wipe
WW
Chris Roper Senior Member Joined: 19/05/2015 Location: South AfricaPosts: 280
Posted: 05:45am 05 Sep 2015
Copy link to clipboard
Print this post
What if the Options were system Variables to allow such things as:
If Not AUTORUN then AUTORUN = ON
Would hold true for all Options and also allow the Running program to test and change then if needed.
Cheers
Chris
http://caroper.blogspot.com/
twofingers Guru Joined: 02/06/2014 Location: GermanyPosts: 1593
Posted: 05:50am 05 Sep 2015
Copy link to clipboard
Print this post
If so a delay would put an end to the ghost.
E.g. a "Pause 500" at the beginning of the program.
Hope you will find your PicKit soon!
MichaelEdited by twofingers 2015-09-06causality ≠ correlation ≠ coincidence
WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2944
Posted: 05:52am 05 Sep 2015
Copy link to clipboard
Print this post
As TZA and Rob have suggested already, I imagine it best to do a 'test' at firmware level and only write to flash if a new different value needs to be written. Definitely would make FLASH last longer too.
Geoff will no doubt take the best approach . . .
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209
Posted: 06:05am 05 Sep 2015
Copy link to clipboard
Print this post
Chris, that is a possibility. However i think it is better if that check is placed in the firmware. Writing to flash should be done as little as possible because every write contains a risk.
Normally flash is written in pages, as often you need to erase a whole page before you can write new values in it.
If values in this page are a mix of OPTIONS and other values then changing a single option can potentially clear all the other options and values when a write fails.
I think that is why we sometimes see a problem where only the program is gone and sometimes the who9le chip is bricked.
This is not that easy to solve as there will always be potential cases like this.
I had similar problems during development when updating chips 'over the air'.
Data was send and stored in RAM, then written to a second bank of FLASH. then verified and finally that second bank was made active by writing another flash area with the right jump instruction.
The first bank with the full program was still there so that when this update failed the first bank will still be active. The code that never changes is the code that gets executed on startup. This checks the integrity of the active 'bank' and if that is ok then executes it. This required a PIC with double the amount of flash then was needed for the program. If the product is build into vehicles, it would not be that easy to update/fix them later so this was really the most important part.
The startup code is very small but enables this whole flash write sequence to go without problems.
In case of MM it can be something similar. When options are written, then that is in a second at that moment inactive area. The code would then need to check which is the latest (maybe a counter that is part of the data written) and use those values.
There is always a fallback, either the previous set of options or going back to defaults.
Edited by TZAdvantage 2015-09-06Microblocks. Build with logic.
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209
Posted: 06:07am 05 Sep 2015
Copy link to clipboard
Print this post
Not if the 'bounce' takes 501 milliseconds. Microblocks. Build with logic.
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10315
Posted: 06:14am 05 Sep 2015
Copy link to clipboard
Print this post
No need for that, a simple CFunction is all that is needed
twofingers Guru Joined: 02/06/2014 Location: GermanyPosts: 1593
Posted: 06:23am 05 Sep 2015
Copy link to clipboard
Print this post
But I think that's very unlikely ... or bad design?
@PeterM
Great! Thanks! Edited by twofingers 2015-09-06causality ≠ correlation ≠ coincidence
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209
Posted: 06:39am 05 Sep 2015
Copy link to clipboard
Print this post
Something you can not control. If the person connecting the power removes it at that exact time you have the failure. It can be anything 10ms, 100ms, 1000ms, etc.
As such there is no good delay time. A reason why even a supervisory chip will not take that risk away.
You can also not solve it with a large capacitor. Because then it will happen at delay+capacitor time.
If we know for sure that it only happens in the first 250ms then capacitance is needed to keep the chip running for at least that amount of time.
And that is unlikely on startup as the capacitor needs time to reach capacity.
This would mean that the ONLY solution in that case is to not write to flash at startup, but wait at least enough time to give capacitors time to charge. It is then a combination of software AND hardware that solves the problem.
It could be as simple as adding a delay in the code at startup to allow for the charging of the capacitor. But if a user does not add the capacitor the problem will still occur.
The size of the capacitor would have to be large enough to do this. And if you have an LCD or other power hungry part then that becomes an practical impossibility.
If it is used with a USB then USB only allows for 10uF. That will not give much time.
It gets darn difficult, as the only solution that is guaranteed to work is not write to flash at all. :(
Which could be an option as it is pretty easy to add some external flash if needed.
Also when an RTC is used there is often some memory in that chip available too.
Edited by TZAdvantage 2015-09-06Microblocks. Build with logic.
Page 6 of 8
Print this page
The Back Shed's forum code is written, and hosted, in Australia.
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.
Print this post
