 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 : MicroMite bug, After reset not working
Page 1 of 2   |
|||||
| Author | Message | ||||
MicroBlocks Guru  Joined: 12/05/2012 Location: ThailandPosts: 2209 |
During my MicroMite workshop where we often removed power to add something to the circuit, it sometimes happened that the MicroMite did not respond anymore. To save time i had a few spare ones, and i put the suddenly faulty ones away to study them to find out what was wrong. After many tries i can now repeat the failure. It does not happen always, about six out of ten times. I did the following. Breadboarded a minimal MicroMite, exactly as in the manual. connected 3.3v, gnd, tx and rx from the USB-Serial and plugged in the USB cable. In TeraTerm after entering an empty line or command the MicroMite would respond correctly. I then removed the 3.3v, tx and rx wires and shorted pins 11 and 12 (Rx and TX on the MicroMite). Note i left the GND wire between the MicroMite and the USB-Serial adapter. Then connected the 3.3v for about 10 seconds. Removed the 3.3v and removed the short. Then connected RX, TX and finally 3.3v. The MicroMite is then 'dead'. I removed the 3.3v from pin 1 and connected it with the 3.3v through a 10k resistor so that i could add a reset button. Still nothing also after a reset. I then took out the MicroMite and placed it in a ZIF socket connected to my Pickit 3. I ran verify and got this: [code] Verifying... The following memory regions failed to verify correctly Boot flash memory Address: 1fc00000 Expected Value: 401a6000 Received Value: ffffffff Verify complete [/code] I then reprogrammed the chip: [code] Device ID Revision = 10000000 Programming... Programming/Verify complete [/code] After that it worked again. My guess is that something went wrong during the 'reset' procedure. Just to make sure i also repeated the above and waited a full minute instead of the ten seconds. The result was the same. I also suspected a faulty chip. I ran the above test on twenty DIP chips and a few SOIC on an small adapter pcb. Eight of those were brand new, the other twelve were just only during the workshop. New or used, the problem is consistent. What happened during the workshop is that probably RX and TX were seen as being shorted while they physically were not. The lines could have been floating, most of the time Gnd, TX and RX stayed connected with the USB-Serial and the USB-Serial stayed connected to the PC. Every time a change was made the power from a regulated 5v and 3.3v were removed. This sequence 'bricked' many a MicroMite, as such it is currently not recommended to use a breadboard to experiment with the MicroMite. However having an exteral power supply is not a rare thing so it could also happen with MicroMites that are on a pcb. Could some of you with a PicKit 3 run the above scenario and see if you get the same results? Geoff, I hope this gives you enough info to find the reason, if you need me to do some more tests i am happy to do that. Microblocks. Build with logic. |
||||
atmega8 Guru Joined: 19/11/2013 Location: GermanyPosts: 722 |
I had simillar problems during beta phase, but could not reproduce them. After The reset procedure the Chip was dead, after reprogramming it worked again. |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2817 |
Gents, This is not a bug. 
Read Page 15; 'Resetting MMBasic'. You just both confirmed this 'feature' works properly. WW For everything Micromite visit micromite.org Direct Email: whitewizzard@micromite.o |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2817 |
IGNORE my last post I mis-read your posts  For everything Micromite visit micromite.org Direct Email: whitewizzard@micromite.o |
||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9308 |
Just trying to clarify something: @ TZA - when you say that after the reset, the MM is dead, does that mean it won't run the program anymore(which is correct for that type of "Hard-reset" and is by design), or do you mean that following the reset, you can't talk to the chip at all anymore? I am just trying to work out if you mean that following the reset, you can't ever talk to the chip again unless you reflash the firmware.... With TX and RX shorted, power on for a second or two, power off, TX and RX separated again - that will wipe the program from the chip, and reset MM to factory default, including the baud-rate. So, you should be able to talk to it using 38k4 baud, but there will be no program anymore. Could you please clarify that aspect? Smoke makes things work. When the smoke gets out, it stops! |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2817 |
Just tried it on six 44-pinners, and four 28-pinners all running released firmware (v4.5). Get the same issue as you guys 100% of the time. There was one time it didn't 'wipe' but it must have been that I hadn't held the short long enough as the program was still in memory when I re-booted. Tried various things too, for example with Autorun option ON and with it OFF but PIC got wiped every time. I did test this feature during early Beta and I was definitely able to wipe a pin No AND have a boot-up so at some stage this function DID work properly. Sorry, I can't remember which Beta it was when it definitely worked. Will keep trying different things . . . . For everything Micromite visit micromite.org Direct Email: whitewizzard@micromite.o |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2817 |
Grogs, Thats the mistake I made in reading their posts the first time - i.e. assuming it had wiped their program. However I can confirm the chip is dead 100% of the time after a reset and you have to reprogram it. Something strange somewhere cos this definitely use to work. WW For everything Micromite visit micromite.org Direct Email: whitewizzard@micromite.o |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9308 |
Flippin' heck - those pesky bugs know how to hide, don't they?!
I am sure Geoff will just LOVE this thread, thinking(as did we all) that the MM was pretty much bug free now....  Smoke makes things work. When the smoke gets out, it stops! |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2817 |
Could it be this: I am using a wire to 'flash' power to Vdd for a period of time to Reset MMBasic. There will be lots of contact bounce during this 'Reset' stage. So maybe the code is only getting so far into the 'wipe' routine (when Tx & Rx are shorted) so that if power is effectively removed (via a contact bounce) then when the PIC see's power bounce back again the code gets 'stuck' in a loop because it hadn't finished the 'wipe' routine the previous time. If however the 'wipe' routine is allowed to execute all that is required, then all is fine. Maybe I try a test with an additional capacitor in place . . . For everything Micromite visit micromite.org Direct Email: whitewizzard@micromite.o |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2817 |
Maybe getting somewhere. With a 10uF cap across the power rail going to the PIC, I now consistently get the 'Reset' function behaving as it should 100% of the time. Remove the cap and back to issue. Then tried with the cap in place to obtain the 'issue'. I managed it when I 'flickered' Vdd to the PIC recreating lots of contact bounce. Even with the cap in place I did manage a couple of times to get the issue. Conclusion at moment is as per previous post; the 'wipe' routine needs to complete fully otherwise the next time it starts over again, it may result in a 'lock up' (i.e. program maybe stuck in an endless loop?). Think it is now over to Geoff to check the MMBasic Reset routine and consider what happens if it doesn't complete this due to at any point the power being 'removed' (as caused by contact bounce). WW For everything Micromite visit micromite.org Direct Email: whitewizzard@micromite.o |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2817 |
TZA, atmega8 Can either of you try repeating your 'reset process' but with a 10uF (or 47uF) capacitor across the 3v3 power rail close to the point where you connect the 3v3 input to Vdd for the few seconds to 'Reset' the PIC. Let me know your outcome if you are able to do this. I am now certain this is the issue from what I am observing here. Thanks . . . For everything Micromite visit micromite.org Direct Email: whitewizzard@micromite.o |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9308 |
Yes, that is a very good working theory, and I could quite understand and expect that when explained like that. No MCU really like you that much, if the PSU is not quite right!  I will be watching this thread with interest...Smoke makes things work. When the smoke gets out, it stops! |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3196 |
Thanks fellows, I have investigated this and I am reasonably sure that the issue is caused by a power bounce while the short is across Tx and Rx. What happens is that the reset routine needs to erase the first part of the boot flash area which ALSO contains the vector table for interrupts, etc. So the steps that the reset routine goes through are: 1 - Copy the vector table to RAM 2 - Erase the boot flash including the vector table 3 - Write the vector table back to the flash leaving the rest of the boot flash blank If the power is removed before step 3 is complete the vector table will be left in its erased state and MMBasic will be essentially disabled as the vector table is critical. TZ proved this by verifying the flash. Address 1fc00000 is the start of the vector table and it was erased instead of containing the first vector (0x401a6000). When I tested this function during the firmware development I used the enable output button on my power supply to cycle the power and this provided a clean power transition with no bounce  .
I will fix this issue in the next release. In the meantime the workaround is to either: 1 - Use a power supply with a clean power on transition. 2 - As suggested by WW, place a large capacitor (47uF or more) across Vdd and ground. This will hold up Vdd during the power bounce. 3 - Delay the Micromite's startup by placing a capacitor on the reset pin as shown on page 14 of the user manual. Thanks very much TZ, you pointed me to the exact issue, you could not have made it any easier for me. Thanks also to WW, you confirmed the issue and then confirmed the fix with a capacitor on Vdd. With help like this bug hunting is so easy .
BTW - A current list of bugs can be found here: http://geoffg.net/Downloads/Micromite/Current_Bug_List.txt Geoff Geoff Graham - http://geoffg.net |
||||
bigmik Guru Joined: 20/06/2011 Location: AustraliaPosts: 2914 |
Geoff, All, If you have a reset switch fitted you could hold it down for a few seconds as you power the uMite up. Regards, Mick Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6102 |
It's still a mechanical switch which means bounce. I couldn't replicate the problem but that's because I use power supply capacitors. Jim VK7JH MMedit MMBasic Help |
||||
| bigmik Guru Joined: 20/06/2011 Location: AustraliaPosts: 2914 |
TassieJim, Fair enough, probably what it needs is a delay in the routine of say 2 seconds before it starts the clear function. Mick Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
|
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2350 |
geoff: what other operations involve writing to this block of memory? for example, does VAR SAVE... make use of it? and what is the block size? could the remainder of that block of memory be used to instead hold predefined constants (pi, trig constant tables, the startup message, etc). intuitively, it would seem a good idea to ensure this rather vital block of memory be strictly read only. rob :-) |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3196 |
Drat. Thanks TZ. I have checked my USB-serial adapters and they do not show that issue, so I will have to get you to test the fix. Attached is Micromite 4.5C Beta 1 (28-pin) which has a more sophisticated algorithm for testing the Tx and Rx pins. It does a fast check first (so startup time is not impacted) but then steadily increases the settling time between each toggle of the Tx line (so that capacitance between Tx and Rx is ruled out). Overall it now waits 500mS before declaring that Tx and Rx are in fact connected together and that the reset should be done. If the power glitches during the 500mS it will restart from the beginning. If there is no short the Micromite will power up within a millisecond. 2014-04-30_073312_Micromite_4.5C_Beta_1_28-pin.zip I hope that you can test it - please let me know how it goes. Geoff Geoff Graham - http://geoffg.net |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
I'll go test it now and let you know the results in about an hour. Still in time to edit this post. :) I repeated the worst case situation where i got 9 failures out of 10 tries and i am pleased to tell you that that test now has zero failures! I will continue with the other tests. Microblocks. Build with logic. |
||||
| Page 1 of 2 |
|||||
 Print this page |
