I'm trying to implement a shutdown function for my unit, and I can't seem to find a method of doing it. Does anyone know how to halt the core and/or shut down the unit in a manner that would require a power cycle to turn back on? Or at least some external trigger to turn back on...?
but in user mode that creates a privelege violation exception if CSR[UHE] is not set, which is (as I understand it) only available in debug mode, and can be undone with the GO command through the debug port... I appreciate any solutions or advice, thanks!
How about a function that you write that puts everything in a safe state, then going into a while (1) { OSTimeDly(TICKS_PER_SECOND); } loop? Why would you actually need to halt the processor?
Put a while(1) inside a USER_ENTER_CRITICAL, and overwrite the whole vector table to point to a ISR that simply returns. This should make the processor core simply do nothing. The only issue that I can think of is disabling hardware output modules (DMA Timers, PWM, etc.). Is this the reason you wish to HALT?
Also, why are you concerned with HALT being uncallable from user mode? The OS runs entirely in supervisor mode...
The halt wasn't my idea, it was spec. Un the event of undervoltage lockout, the system should halt. Trying to talk them out of it, and I think I'm making some headway. The request was that everything shut down, all gpio goes to a low state, and core halts so that nothing can make it go again other than a power cycle.
My preoccupation about user mode came from page 1286 of the MCF54415 manual... it outlines it there.
"3. The execution of a HALT instruction immediately suspends execution. Attempting to execute
HALT in user mode while CSR[UHE] is cleared generates a privilege violation exception. If
CSR[UHE] is set, HALT can be executed in user mode. After HALT executes, the processor can
be restarted by serial shifting a GO command into the debug module. Execution continues at the
instruction after HALT."
Ah... No worries on that. The processor is never in user mode.
Also, just to clarify, not all gpio's should go into a low state, all outputs should go into a low state. If you try to drive what is normally an input into a low state, you'll probably burn out that channel as things fight over the line. Just a heads up that if the spec said gpio's you probably want them to correct/clarify that.