 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 MK2 loosing programme
| Author | Message | ||||
| DaveC166 Regular Member  Joined: 13/09/2012 Location: New ZealandPosts: 44 |
Hi guys I am bench testing a Umite MK2 PWM controlled 12v SLA battery solar regulator which supplies +5V to a 16x2 LCD and Umite +3.3v LDO Vreg. I have encountered a problem with the CPU SLEEp comand. I have the comand CPU SLEEP,5 active when the solar panel is not charging.3 times out of 5,If i disconect the +12V battery connection when in sleep the Umite prog memory gets wiped. List when running MM EDIT shows nothing MEMORY shows no prog memory used and no variables. I Then use MM EDIT to reload my file and the Umite MK2 is a PWM charge controller again, untill i disconect power while CPU SLEEP,5 is active. I have remarked out The CPU Sleep,5 line and The UMITE MK2 survives power disconnects all the time . Any thoughts on this ?  .
|
||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9063 |
Interesting. I have just finished building a PCB that makes use of the sleep command and wakeup pin, so I will load some test code and do what you have done, and report back if it happens to me. So, it would seem that code is only being lost, IF the MicroMite is in sleep mode when there is a power loss - correct? I will run some tests later and get back to you. Smoke makes things work. When the smoke gets out, it stops! |
||||
CircuitGizmos Guru  Joined: 08/09/2011 Location: United StatesPosts: 1421 |
What about your console lines? Could there be a condition where on power up the code is cleared (feature) and the problem is unrelated to sleep? Micromites and Maximites! - Beginning Maximite |
||||
| DaveC166 Regular Member Joined: 13/09/2012 Location: New ZealandPosts: 44 |
Thanks for the replies. After more testing i managed to wipe the umite prog without the CPU Sleep active. I will see what results from disconecting the The USB to TTL console connection adapter first as per Circuitgizmos suggestion. One other problem ive encountered is If PWM is active on PIN 4 and i CNTRL C to get back to the console, Pin 4 still outputs PWM and my battery overcharges. Is this normal for the UMITE |
||||
| DaveC166 Regular Member Joined: 13/09/2012 Location: New ZealandPosts: 44 |
CircuitGizmos, you were spot on. Once i removed the USB to TTL adapter cable from the Umite no more problems.I had forgoten about the hard reset procedure for the Umite.Only 1 of the three different USB/TTL devices i have causes this problem. Now to sort out PWM still active after a CNTRL C |
||||
BobD Guru Joined: 07/12/2011 Location: AustraliaPosts: 935 |
Have a look at the documentation. I think when you start a PWM it runs until you do something about it. Control C may not be enough. |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2289 |
a few folks have commented about the PWM outputs carrying on upon the program exiting, and i have wondered about posssible effects and alternative strategies. it seems that there are several conditions for a program to stop running, and that it may be desirable to set different behaviour for each one: 1. a program error occurs 2. a deliberate exit occurs 3. the user presses ctrl-C in each case the options are: a. continue running PWM outputs and maintain digital output states b. stop PWM outputs, but maintain digital outputs c. stop PWM and set all pins to input/unassigned this may be something for geoff to consider in a future release. similarly, there have been discussions in the past about the clearing of program memory. in the beginning, the reset detection was easily triggered by accident, so geoff tightened up the algorithm used to detect the short between TxD and RxD. perhaps it is time to think about requiring a "reset key" to be used. one simple approach would be a transistor inverted connected between TxD and RxD - ie, configure RxD with a weak pullup, place an NPN transistor with collector to RxD and emitter to ground, with a resistor from TxD to the base. this would be extremely simple to construct, and would provide a close to 100% foolproof way of detecting a request to clear program memory. if the TxD pin could be temporarily configured as an analog input, it may also be possible to detect the 0.6v base voltage drop as an extra failsafe. cheers, rob :-) |
||||
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
Could be done in software too. After detecting a short wait a few seconds then display a message on the console 'Are you sure you want to delete the current program?" Wait a few seconds for an answer. No answer or a 'N' would restart the mcu and run the existing program. If 'Y' then do the erase. That would also 100% prevent accidental erasure. The only reason you want to short the console pins is to enter a new program. As such a terminal will always be connected. Microblocks. Build with logic. |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2289 |
a good plan, except what if you don't know the baud rate that the micromite's console is currently set to? the plan would only work if the question/answer was always done at a fixed baud rate, 38k4 being the obvious choice. but then what if an 'unintended' short was briefly present, triggering the message to be sent at 38k4? and that that baud rate caused garbage characters to appear on your terminal screen at the baud rate that the terminal was set to? this would look confusing. cheers, rob :-) |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3659 |
Rob - good points. It does seem a bit too keen to erase at the moment, though... John |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
I agree Rob, Still better then a unintended delete of the program. It would be trivial to switch baudrate to fixed value to send that message. It is run before anything else AND only when a short is detected. I am also of the opinion that an erasure of the program should be impossible without human action. Maybe just capture a sequence from the terminal is enough. Like a CTRL+] repeated three times. If the baudrate is unknown then well you should know it when you build it. Forgetting the PINCODE (only reason to do the reset) AND forgetting the baudrate, that is preventable, so going trough a little more trouble doesn't sound too bad to me. But even then just trying a range of baudrates is better then having a uMite fail far away and unattended. If that is difficult to implement then why not extend the detection of the short for a much longer time. Maybe even a minute. The change that an erasure happens unintended will be dramatically lower but not impossible as not all conditions can be foreseen. Microblocks. Build with logic. |
||||
 Print this page |
