 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 : "Half" dead micromite?
| Author | Message | ||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9066 |
This on is weird.... 
150 uM chip(28 pin), working just fine last night, then I had a power glitch caused by my not pressing the power switch right - would have caused quite a lot of noise on the power supply. Now the uM is totally dead. God bless the console, so I connected that up, and no program anymore, no edit anymore, no commands at all anymore. BUT - the serial interface still works at 38k4, it's just the uM won't process anything. Fully regulated and decoupled supply - I think the problem was just my mistake of holding the switch half on, which would have produced very dirty power to the unit, but I figured that the regulator and decoupling caps would have saved the chip, but perhaps not? This is all I get when I connect up the terminal: 
Smoke makes things work. When the smoke gets out, it stops! |
||||
| JohnS Guru  Joined: 18/11/2011 Location: United KingdomPosts: 3663 |
Tried erasing and reprogramming it (via ICSP)? Give it a go... John |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9066 |
UPDATE: OK, I have re-flashed the chip with the firmware, and it is all up and running again, but I am curious about this situation, and is there anything anyone can suggest to help prevent this from happening? Can't really have the firmware getting corrupted cos of a dirty power condition. Perhaps a cap across the power switch?(which is just a mechanical switch in line with the 12v input power) Smoke makes things work. When the smoke gets out, it stops! |
||||
Justplayin Guru Joined: 31/01/2014 Location: United StatesPosts: 309 |
Same thing happened to me. I programmed several chips and verified to operation of each. Next day, I hooked one up and it worked fine. Disconnected the power and then plugged it in again a couple minutes later and got nothing. Console seemed to be working but nothing from MMBASIC. Downloaded the hex file again and now it working. All the other chips I programmed the first day seem fine too. I'm glad I invested in a PICkit 3. --Curtis I am not a Mad Scientist... It makes me happy inventing new ways to take over the world!! |
||||
| hitsware Guru Joined: 23/11/2012 Location: United StatesPosts: 535 |
I'm sure you guys have been .... BUT ? Do you always do a reset before you decide somethings really awry ? I've been fooled that way several times ... |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9066 |
@ justplayin - Thanks for the feedback. Interesting.... @ hitsware - Not necessarily, it's just that for the most part, it is quicker and easier to attempt a re-program of the device, then it is to play around for too long trying to work out why it is NOT working correctly. If a reprogram fixes the issue(as it did in my case), then you can move forward and at the same time, try to find and fix what caused the failure in the first place. I am still seriously thinking of a cap across the switch contacts, but am open to opinions on that.... Smoke makes things work. When the smoke gets out, it stops! |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 5913 |
There was a problem with the initial release of MMBasic for micromites (V4.5) From the change log: There were also problems with rapid power cycles so a capacitor on the mite side of the power switch is probably a good idea. If it happens again, try resetting by shorting out the Tx/Rx lines on power up. Knowing if this works will help determine the problem and help with a permanent solution. Jim VK7JH MMedit MMBasic Help |
||||
| hitsware Guru Joined: 23/11/2012 Location: United StatesPosts: 535 |
> Not necessarily, it's just that for the most part, > it is quicker and easier to attempt a re-program > of the device, then it is to play around for too long > trying to work out why it is NOT working correctly. Easier to re-program than to reset ? Come on now .... |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9066 |
Oh, I see what you mean - you mean using the MCLR pin, right? I thought you were talking about resetting MMBASIC. If the firmware IS corrupted, then standard resetting won't help you anyway.  Smoke makes things work. When the smoke gets out, it stops! |
||||
| TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 5913 |
No, but if it's your program that has gone haywire, a reset would work and it would be nice to know if it is your program or something more sinister. On a PC I will always try a reboot before rushing to a re-install. Jim VK7JH MMedit MMBasic Help |
||||
| hitsware Guru Joined: 23/11/2012 Location: United StatesPosts: 535 |
I mean temporarily short pin 1 to ground .... Assuming ~10 k Ohm pin 1 to 3.3 V |
||||
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
I am sure it is caused by the same issue as in this topic: http://www.thebackshed.com/forum/forum_posts.asp?TID=6512 If this still happens then it means the routine to check for a short between the Rx and TX is not robust enough in all cases. Personally i would like that there would be no such routine at all, to prevent this even in rare situations. Murphy's law says it will happen when you least expect it. To prevent such things i always use a supervisory chip that holds the microcontroller in reset while powering up. like this (i use the mcp120): 
Microblocks. Build with logic. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3663 |
Looks good. John |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2290 |
hi, may i ask what software and programmer each of you are using? cheers, rob :-) |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3165 |
I would like to have another way of resetting the Micromite other than reprogramming the firmware. The reset facility is needed because there are too many ways that the console can be rendered inoperable (eg, forgetting the PIN) and not everyone has a PIC32 programmer. Does anyone have any ideas on a better way of triggering a reset? Geoff Graham - http://geoffg.net |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2290 |
having thought about this on several occasions in the past, nothing came to mind that was much better and as practical as the current method of shorting RxD and TxD. at the same time, it does make it dangerous to expose console access to an end user when designing a device with an embedded micromite. i did toy with the idea of what single component could be connected between the pins as a 'key'. one idea could be to place a diode between RxD and TxD. combined with manipulating internal pullup and pulldown resistors it would be possible to verify that a diode is present, causing an entry into "prepare to reset" mode. connecting the diode in reverse (without cycling power) could then be the trigger for "do full reset". this would be hard to duplicate non-deliberately. but then, would this be too complicated and fiddly for beginners? another way could be to use a certain value of capacitor. again, it may be possible to use internal pullups/pulldowns to implement a simple check for a capacitor being present of about the right value. this is more practical for beginners, but possibly more complicated to make work. i'm not convinced that either of the above are good solutions. but what would be handy, based upon the occasional complaints, would be an undocumented persistent option command such as: OPTION RESET OFF|ON that would disable the reset, to only be used with extreme caution. it would need to be implemented as a magic number for OFF stored in memory - not just a simple single-bit flag. btw, i was thinking about reclaiming tokens... an idea could be to do away with the CPU command, replacing it instead with the volatile command: OPTION CPU <speed> and to allow sleeping with: PAUSE SLEEP or: PAUSE -1 cheers, rob :-) |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
I think a combination of a check for a short between the TX and RX and a command given through the console. If there is a short set a flag.. When starting up check if that flag is set and ask through the console for 'Are you sure you want to erase the program (YES/NO)?' a YES or NO has to be typed within 30 seconds. If YES, Display a warning "Do NOT remove power! reset the flag, do the same as a 'NEW' to clear program memory reset the PIN code. display "Program memory is erased, pin is reset." If NO or a timeout reset the flag continue as normal. Microblocks. Build with logic. |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9066 |
I'm using MPLAB X IPE from the Microchip programming package, with a PICkit3. Smoke makes things work. When the smoke gets out, it stops! |
||||
 Print this page |
