 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 MkII V4.6b Update
  Page 2 of 2 |
|||||
| Author | Message | ||||
MicroBlocks Guru  Joined: 12/05/2012 Location: ThailandPosts: 2209 |
Would this be a solution: [code] firmware starts Set console TX to input with pullup and check if it is grounded (logic '0') if TX pin = 0 delay 1 second if TX pin is still 0 delay 5 seconds to allow user to remove the TX to ground connection (a button will be easier to use) set baudrate to a default value and any other option to ensure access to the console. Send the 'copyright message'. Wait for a key (about 1-2 seconds). If key = DEL (or any other chosen key or key combination) Ask for the Pincode (with a timeout of around 2-3 seconds) If Pincode is correct release the 'lock' goto normal prompt else Ask to deleted current program If user answers Yes (upper and lowercase is important) Delete the basic program, set all options to default endif endif reset the chip endif endif endif run the program normally [/code] I favor user interaction. :) The above sequence will allow a fast start up as the TX pin will be used to determine if a reset routine is called for. The delays after that is 1 second to prevent a false reading. If it was false then the maximum startup delay is 1 second. Worst case false reading is about 7 seconds. Actually the current method using a short between RX and TX will also work but it is the user interaction that makes it 100% error proof. The other solution is to just remove the whole reset routine, it causes more harm then it prevents. Microblocks. Build with logic. |
||||
| PicFan Senior Member  Joined: 18/03/2014 Location: AustriaPosts: 133 |
I think the best and easiest solution is the way with the PICKIT. It is cheap and will sooner or later required of each? Wolfgang |
||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9073 |
Hi TZA. 
Nice bit of logic there, but that also assumes that the console is working and that the baud-rate is known. You can't use DEL keys or enter pins, if the baud-rate is wrong, and it's setting has been forgotten. 
Like you, I reckon just scrap the resetting routine altogether - it could never ever be an issue, if it was never there to accidentally become invoked in some way - intended or not. PICAXE chips can also be killed by incorrect use(not that I would know, or anything like that!!!   ), requiring the user to purchase totally new chips as you can't reflash them, as the PICAXE source is closed, so at least with the MM, you can just re-flash the chip, worst-case scenario.
EDIT: Hi PicFan - you beat me! Smoke makes things work. When the smoke gets out, it stops! |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
You missed this line: 
[code] set baudrate to a default value and any other option to ensure access to the console. [/code] Microblocks. Build with logic. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3675 |
One thing that can perhaps be a problem is where the console is connected to another uart. The reset routine needs to be sure such another uart is neither echoing anything sent nor holding the Rx/Tx at low or high. I've had the routine clear the flash when I didn't expect it and am not sure what it detected that caused it to do the clear. It was a nuisance but I have an endless supply of PIC32 programmers nowadays so once I figured out what had happened (took a while) it was easily reprogrammed. (I didn't have a PIN set. Didn't have any weird settings at all.) John |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2292 |
geoff: you put an extremely strong case for retaining some sort of "emergency recovery" system. i'm going to push again for this being in the form of a single transistor "key", to be connected when required to TxD and RxD as below: 
the micromite power-on code would need to perform the following test before configuring the console: 1. configure pin 11 as an open-collector output with internal pullup resistor 2. configure pin 12 as an input with an internal pullup resistor for i = 1 to n, perform the following steps 3. set pin 11 = LOW 4. pause 10mS 5. check to see if pin 12 is HIGH 6. set pin 11 = HIGH 7. pause 10mS 8. check to see if pin 12 is LOW 9. if the expected pattern has been observed on pin 12, enter erase/recovery routine a suitable value of n may be 5, giving a total time to conduct the test of around 100mS. the output pattern generated will then be 0101010101, while the pattern read back when the key is present will be 1010101010. electronically, this is about as simple as it gets. the only component the user needs to furnish is a spare BC547 (or similar) NPN transistor. the configuration of pins of 11 and 12, while checking for the key, will not conflict with an attached terminal, and i can think of no way a terminal could emulate the behaviour of the key accidentally. cheers, rob :-) |
||||
| ajkw Senior Member Joined: 29/06/2011 Location: AustraliaPosts: 290 |
Does the PIC enter any sort of running state if there is no power on AVdd? Or perhaps, if AVdd is lower than Vdd could that be measured internally? |
||||
| PicFan Senior Member Joined: 18/03/2014 Location: AustriaPosts: 133 |
Hi Geoff ! The DHT22 command is now working perfectly. 24 hours test every 5 sec. read, no problem! Very good, thank you! Wolfgang |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8600 |
Both Robert's transistor idea and the DS18B20 are effectively the same - i.e. there should be a reset "dongle" that can be connected to the console pins on power up to reset the chip. In fact a short between the pins is the simplest possible reset dongle. So what are the assumptions and constraints we can work with? First, under a normal start-up we cannot assume anything about the polarity of the RX line as an attached console may be normal or inverted or the line could just be floating Second, under a normal start-up we can't output on the RX line as we may be driving the pin against a valid incoming signal Third, under a normal startup we don't want to do anything on the TX line which can be misconstrued by a connected Micromite as a RESET or can cause problems for any other connected serial device - HOWEVER, even with OPTION AUTORUN ON set the Micromite outputs the MMBasic Copyright text so connected devices need to cope with this anyway. Fourth, if we want to reset the chip then we will need to reprogram it so irrespective of its use in a particular circuit at that point we will need to connect the console lines AND at that point we can only use the console in normal and not inverted mode until we set the INVERT or AUTO option My proposal is therefore to keep the simple SHORT dongle but to recode the Copyright text output so it checks character by character whether it has received back the character it has sent. The code for this needs moving in main.c so it occurs before initialising Basic or any other parts of the normal initialisation that could go wrong. It would also be preferable if the serial I/O was conducted under polled rather than interrupt control. The test has to be character by character rather than the whole string as otherwise input from another connected Micromite could be misconstrued as a RESET Under this approach two interconnected Micromites could just conceivably reset each other if they power up absolutely simultaneously but perhaps the message should be that use of the console ports for inter-processor communication is best avoided. |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
It is not good enough to test for the 'dongle', short or whatever. The current code already determines if there is a short over a longer period. Just to make the case clear: It is not ONLY the determining that a clearing has to be done that causes a bricked chip. It is the power loss or hard reset that occurs WHILE the clearing is done. It leaves the flash data in an erroneous state that is unrecoverable afterwards.Basically a vector is not filled with the right value. This is the main reason i suggest 'human interaction'. The clearing of the flash is then under human control. Both the decision to start the clearing and the waiting for the clearing to be ready should be a human decision. Again, better to leave the routine out. Problem solved once and forever. Microblocks. Build with logic. |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2292 |
i'm shying away from the DS18B20 idea now, as the check for it's presence could generate traffic that an attached terminal may try to interpret as garbage characters. a couple of points on your suggestion: 1. problems with interconnected micromites could be circumvented by having a device-unique section in the startup message. examples include a checksum on the basic code contained within, the value of the onboard die temperature sensor, or simply some number preset by the user. btw, i can see it being useful to have two micromites connected together by their consoles in some applications. however: 2. even checking for an echoed message still allows for unintended loss of code when an unpowered terminal provides a signal path between TxD and RxD while not (in the unpowered state) shorting either to ground. when unpowered, a terminal can do what it likes with the RxD and TxD lines - the unpowered behaviour is unspecified. it would, for example, break no rules to have a terminal that used a relay to deliberately isolate the internal RxD and TxD lines, and short together the external pair. effectively this presents a "shorted link"; while a design that did this would be odd, it would not be illegal. couching in another way: a design of MZX232 chip that connected TTL TxD and RxD signals together when Vcc was removed would be a valid design. cheers, rob :-) |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
I think the bricking of the chips happens because of a trigger happy MCLR or power drop. Once a pic powers up there is no certainty that the supplied voltage is of good quality. When by whatever means the clearing routine is entered and starts executing it is vital that power is uninterrupted and no reset occurs. This can never be guaranteed without elaborate extra electronics! If the clearing goes good, you have a chip that still functions, only the basic program is wiped and setting returned to default. The observed problem is that the clearing of the flash is interrupted. My guess is the voltage goes down/not stable or/and the reset circuitry is not good enough. I have had lots of problems with suddenly erased mites when using the power from a USB/Serial converter. Once i had a more solid reset circuitry (supervisory chip) the problem went away. Still, when there is a sudden drop of power while it is clearing the flash the problem remains. It can not be foreseen or prevented at all. Only human interaction will work. Microblocks. Build with logic. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3675 |
In my case the reset code should never have done any clearing of the flash! It made an unwanted false decision to do the clear. I cannot see theoretical or actual multiple resets on MCLR on anything as being the cause. How? No, it's the routine that's the problem. In my case it didn't really matter as it was not a deployed board but one I was using for development. John |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
The routine IS the cause. A single reset or a power failure at the wrong time will end the routine prematurely leaving a corrupted flash. It is like ripping out your pickit 3 while it is programming the chip. I am guessing that the routine needs to write a complete page in flash to clear the options. In that same page there is data that is needed to start correctly. Either the options data have to have their own separate page so that the worst that can happen is a corrupted options data page which can be cleaned by doing it again. Or if a complete flash page is not available remove the routine completely. Microblocks. Build with logic. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3675 |
That explanation does not fit the facts. The routine is a problem, yes. Multiple resets are irrelevant because the routine should never have started to clear the flash on any of them (even if there were multiple which I cannot say there were). John |
||||
CircuitGizmos Guru Joined: 08/09/2011 Location: United StatesPosts: 1421 |
I wish that the startup/copyright banner wasn't there. That would allow for using the console as a serial port to a device (other than a VT100 terminal). What about having the Rx/Tx short not do a complete clear, but have it restore the baud to 19200, restore clock, etc. Provide a prompt that won't list the program, but will allow NEW to clear the code. Micromites and Maximites! - Beginning Maximite |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3675 |
Or an OPTION that means you never want the clearing, something like OPTION I OWN A PICKIT SO DONT SELF-CLEAR FLASH John |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9073 |
That's not a bad idea, PROVIDED that any PIN that was in place, still remains in effect. That way, the console would be set to a known baud-rate, but you would still have to enter a PIN if there was one. The whole idea of wiping the flash, is so that people can't just do a hard-reset to get access to your code if they were of a plagiarizing state of mind. If you get rid of the hard-reset routine, that takes that possibility out of the equation(my personal preference), and it would seem that if you use IDE to set the config bits such that reading the existing flash is refused, then any code in the device is REASONABLY secure. You can re-flash the firmware(which will wipe-out any program in the process), but you can't read the device back. This is exactly how PICAXE do it, and it works well. Smoke makes things work. When the smoke gets out, it stops! |
||||
| Page 2 of 2 |
|||||
 Print this page |
