-
Where are the brakes? (PICkit3 LPC demo project - terminate!)
Posted by PerranOak on 12 May, 2017 16:31 -
Hi,
I successfully ran my first project on the PICkit3 LPC demo board - it only lights a LED but I was pleased. It has an infinite loop which I know is poor but it was the project that Microchip gave.
What they didn't say was how to terminate the running system.
I looked on menus, right-clicked everything and even tried <Break> and <ctrl> C (dunno where I got that idea).
In the end I closed the project, exited MPLABX and tuned-off the laptop and it still ran; I had simply to unplug everything!
There must be a better way?
-
if the MCU is running it is running. the while(1) loop means exactly that the mcu will excecute that bit of code ad libitum, until a reset or a power cycle
however, during debugging, you can pause and stop excecution. since the MCU is in debug mode it can't run the code unless the debugger gives its go. -
Ah. So how do I do that?
Thanks. -
Quote
It has an infinite loop which I know is poor
All functional microcontroller code is an endless loop. Even if it is designed to only run once per bootup, it usually ends in an infinite loop. To make the micro actually turn off (as opposed to hibernate/sleep in a low frequency clock setting), you would need to control its reset pin and/or powersupply.... with another control circuit.
If you just want it to stop temporarily, while dev (say one of the outputs is connected to something like a large motor or something loud or annoying, and you are not finished coding), you can click the "MCLR button" at the top of the IDE interface to hold the MCLR pin high. This will hold the micro in reset, so long as MCLR is enabled.
Just because holding the micro in RESET will stop the internal clock, it still doesn't mean it will turn your circuit "off." This will put all the I/O pins into input/high impedance mode. Most of the time, you will have to define "off" (as per pin states) yourself, based on what is connected to the micro. Output hi/low might be necessary (or at least the lowest current draw) for your circuit. Hence, why nearly all code will "end" in an infinite loop after shutting off unneeded power consuming peripherals, slowing the clock, and defining pin in/out/pullups.
I'm not 100% positive about this, but I think the "end" command in say an IDE really just inserts an infinite loop of the "nop" command, in and of itself. Something akin to 1)turn off global interrupts 2)do nothing 3)goto 2.
If the micro could turn itself off in code, it would have no way to know when to start running, again. Sure, it can have bits to tell if the power was cycled or browned out. But in order to check those, it has to run. So you got a chicken and egg problem.
In assembly:
banksel INTCON
bcf INTCON, GIE
nop
goto $-1
or
banksel INTCON
bcf INTCON, GIE
Sleep
This is how you permanently stop your PIC micro in code, barring power cycle. If you don't have an ISR, you don't need to turn off global interrupts. The clock will still run, the processor will still process, and all your pins will retain state you last defined. Unless you use external control circuit, this is the best you can get.
-
Right, I see. I guess I'm used to PCs and being able to turn-off the "ordinary" way.
So, when developing a programme you may run something then want to stop, alter the code, reload and run again. So do you use the MCLR to high to stop it while you change the code?
Is it safe simply to unplug the PICkit3 from the PC or the MCU from the PICkit3?
Cheers. -
Yes, using the MCLR button is a very convenient way reset and/or to hold the PIC in reset. As long as your circuit is ok with all the I/o's being high impedance. I frequently use MCLR during firmware development. This is why there is convenient button in the IDE GUI for accessing MCLR.
it is safe to unplug the PK3 from the PC, but it will waste a lot of time disconnecting and reconnecting. Disconnecting the circuit from the PK3 is going to be slightly easier. But because you are going to be doing this quite a lot while developing your code, even clicking the MCLR box is going to get annoying.
It is best to setup your code (and/or circuitry) so that you don't have to turn it off, at all. This may take several diferent "dev" setups depending on what is in your circuit and how complex your firmware and what part of it you are working on. Then fix it at the end, once you have worked in all the features and worked out all the bugs. The PIC low pin count circuit, for instance.... I have used this exact board, myself. I don't recall having any reason to want to stop this code during dev. So what if the LED's are on? If you want to turn the thing off before you go to bed, just unplug it. Let it run while you are writing new code. Reflash it whenever you want. There are no gears grinding nor motors/FETS burning out due to logic/timing issue nor lights dimming while this board is running. If it's not making noise, consuming a lot of power, or letting out the magic smoke... just don't look at it while you are writing new code.
Uness you have altered the circuitry, there is nothing you can do in code to break this board.
If you don't want to have to unplug it at night to make the LED's or whatnot turn off, adding a soft on/off button is perhaps your next project. Pick a tac switch and start writing some code.
In case I'm on the wrong scent: If you are powering your board from the PK3, you can also turn off PK3 power out... should be able to find it in the menus somewhere's.