 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 3 of 8   |
|||||
| Author | Message | ||||
twofingers Guru  Joined: 02/06/2014 Location: GermanyPosts: 1593 |
Could be interesting!  causality ≠ correlation ≠ coincidence |
||||
| viscomjim Guru Joined: 08/01/2014 Location: United StatesPosts: 925 |
Just ordered a couple of 150s in a SOIC package so I can test this in the same exact situation as where my 170's are doing this weirdness along with a few different Vcaps just to test. I see that the mmbasic is at ver 4.5E as the last firmware available for the 150's but the memory is smaller. Using mmedit to get rid of all spaces and comments, I can get my program down from 19K to about 10k so this will work. Can't wait to try. Need a solution and if this works, I can switch over to the 150's for this particular project as I am not using any "new" features thank goodness. EDIT... I just remembered that there was a bit of a problem with I2C with the older mmbasic. I hope this was fixed before it went to the retirement home as I am using I2C in this project. As Homer would say, DOAH!!! |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10315 |
Have anyone with this problem tried with a MCP100 (or equivalent) power management voltage supervisory device? The MCP100 is available in a TO92 package so very easy to include in any circuit, including breadboard. Has anyone with a Skinnymite or Explorer64 which include such a device had the problem? |
||||
| viscomjim Guru Joined: 08/01/2014 Location: United StatesPosts: 925 |
Hi Matherp, just took a look at supervisory ics on microchip. There seems to be quite a few of them. How would one choose the right one for the uMite? There are a lot of options. I hope I don't have to use one of these as I have a few boards already made and this would require a redesign. I am still hoping that the fact that mmbasic never seems to get wiped out that there is still hope that this can be fixed in firmware. This could be a big problem for battery operated devices that get powered up and down frequently. |
||||
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
I recall that recently there was a post why when programming a MM it always failed a verify. It seemed that when a chip gets programmed it is then reset before reading the flash contents. The flash contents are then not the same because the MM firmware modifies some values. Could it be that MM not only changes those values that very first time, but sometimes after an reset/powerup and then not be able to finish the write leaving an 'empty' chip. What i think could happen is that when power is applied to the chip it starts executing code unreliably (this would explain why it not happens always). The code then reads that location gets the wrong value and then makes the conclusion it is a fresh programmed chip. It then changes the values in flash, and that either fails or not but that leaves a chip without an basic program or worst case a non functioning firmware. The supervisory chip will not only delay a startup to prevent this, but also holds the chip in reset when a brownout is detected. Without looking at the source there are i think two situations were the flash is modified by the MM firmware. 1 freshly programmed chip, and when !!!!!!!!!!! are detected on the console. It is highly unlikely that the pincode sequence is the culprit. I would focus on the other routine that modifies the flash. Microblocks. Build with logic. |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10315 |
After programming the processor writes the default values for the OPTIONs into flash. This should only happen the very first time. HOWEVER.... I think TZ may be on to something. The startup code is: LoadOptions(); // populate the Option struct from flash
if(Option.Baudrate == 0xffffffff) ResetAllFlash(); // init the options if this is the very first startup If because of power supply issues during initialisation the read of option.baudrate from flash sees 0xFFFFFFFF then the program will certainly be erased. Without question a supervisor chip is the best way round this, or use one of the various circuit for delaying MCLR going high during power up |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2442 |
what would happen if that line was simply removed? would it then be possible to instead start up a 'new' maximite while holding down the '!' key to achieve the same result? cheers, rob :-) |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
Maybe adding a CRC to that flash area might prevent accidental overwriting. It might also be better to not write to flash unless under program control. This would mean that all de default values 0xffffffff should be workable options. Even better is it possible to have that area filled while programming the chip. Those values could be part of the hex file. Then that line of code can be removed. Microblocks. Build with logic. |
||||
| viscomjim Guru Joined: 08/01/2014 Location: United StatesPosts: 925 |
Matherp, is there any way you can look at 4.5E for the 150 to see if that has the same start up code? If it doesn't then this would be a good way to check when I get my 150s in from digikey. |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
Could not edit my previous post. A line should read: It might also be better to not write to flash unless under BASIC program control. Microblocks. Build with logic. |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10315 |
Sorry this code isn't online and I haven't got a copy Robert, TZ I think yours various ideas could have some merit but this is definitely one for Geoff. HOWEVER: if the mechanism we propose is correct this means that the code is probably executing junk anyway so you don't want the code to continue through startup because who knows what else may go wrong later. My view FWIW is that, if this is the issue, the current situation is actually a good hint that the circuit/power supply need improving to rectify the issue rather than coding so that the program will/may continue into a completely unknown state |
||||
| viscomjim Guru Joined: 08/01/2014 Location: United StatesPosts: 925 |
Hi Matherp, the 4.5 code is HERE toward the very bottom of the page and is called "Original Micromite Firmware 4.5E for the PIC32MX150F128 chip". The way the circuit is designed is somewhat common to use a barrel connector for a power source to the board. Using a regulator and appropriate filter caps on the board as usual and powering from a 12v lead acid battery without using a barrel connector has usually worked for my battery operated projects without fail. It seems where I am running into problems is when the barrel plug is plugged into the barrel jack there seems like once in a while there can be some "bounce" for a lack of a better word. This seems to sometimes, not always, make the uMite want to wipe out the program. I wonder if it would be possible to "modify" the firmware to not do the erase flash portion and do some testing to see if indeed the uMite goes into some weird state when this "bounce" occurs. I would be willing to do the testing as I have 3 setups that I can make fail this way, but have no clue on how to modify the firmware. |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
I think the solution MUST ALSO be in software. The hardware is much more difficult to control. Moisture, temperature, vibrations etc.. can all occur and have consequences when the software concludes the wrong thing under unstable conditions. Flash should never be written to at startup. It may be written to when stability has been detected. Stability being MMBasic has been startup AND a CRC has been calculated and maybe some other means to make as sure as possible the system is stable. Then only when a command is given by the user or under MMBAsic control should a write to flash be needed. Even then it can go wrong, so a CRC will make sure the part that is written too is valid. The OPTIONS area should never be written to unless from MMBasic prompt. Saved variables checked with a CRC will make sure those variables are valid, when not then those variables will be empty. An MMBAsic program can then check for that and make appropriate decisions. Above would only work when OPTIONS can be used from basic code so that for instance setting an LCD would be part of the program that runs. Microblocks. Build with logic. |
||||
| twofingers Guru Joined: 02/06/2014 Location: GermanyPosts: 1593 |
With respect: I don't agree! (sorry!) I think IF we can say the MX150 and the MX170 with MMBasic 4.5 is working without issues then we should take a look at the software side. @Jim Firmware is not the source code. 
I think everyone can Geoff ask for the sources. Regards Michael causality ≠ correlation ≠ coincidence |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10315 |
That is the hex file - I need the source. viscomjim Just try a 100K resistor from MCLR to VCC and a 1uF capacitor from MCLR to GND. That will delay MCLR going high for about 100msec. Should be easy enough to hack wire for a test |
||||
| viscomjim Guru Joined: 08/01/2014 Location: United StatesPosts: 925 |
ooops. Firmware is not the source code! Wasn't thinking... |
||||
| viscomjim Guru Joined: 08/01/2014 Location: United StatesPosts: 925 |
@matherp, I will give that a try. @twofingers, are you saying I can run 4.5E on a 170? If so that would be something I can do quickly as my 150s are not yet shipped and I have all 170's running with this problem. |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
Maybe someone can compile a version without that line for you to test. Same chip, same environment just one line of code commented out. That would make clear if that is the offender. Also you can use a pickit3 to read the contents of flash before and afterand see which areas are different. With that information the part of the code that changes it can be found. This how i isolated the PIN code reset problem before. Microblocks. Build with logic. |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10315 |
Not that easy unfortunately as that is the line that sets up things like the baudrate for the console first time in. I can't quickly think of a simple hack that does what is wanted but that wouldn't have unintended consequences that would further confuse things. Like I said before, I think this is one for Geoff to comment on but I would like to know if it ever occurs with a better circuit controlling MCLR during power on. |
||||
| twofingers Guru Joined: 02/06/2014 Location: GermanyPosts: 1593 |
There is a version (4.5D) for a 170. Michael causality ≠ correlation ≠ coincidence |
||||
| Page 3 of 8 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
