deinitialize peripherals in 52259?

[Leong]

Hello there, 

Is there a way to easily deinit all peripherals other than resetting? I wrote a bootloader that uses some interrupts and io's that I want them to be flushed out when the application starts. but since this is a jump, i don't think there is a good way to 'reset' all peripheral IO's. To be safe, I would like to deinitialize IOs at the end of the bootloader, any idea?

Regards

Guoliang

[mjbcswitzerland]

Hi

Most peripherals can be powered down - as long as the new application powers up peripherals that it uses, they will then be in a de-init state. (If this can not be assumed, you could power all peripherals down and them back up since this is like reseting each peripheral).

And mask all interrupts in the interrupt controller.

Regards

Mark

[Leong]

Thank you Mark, can you elaborate how to power down peripherals?

Regards

Leong

---

mjbcswitzerland wrote:

Hi

Most peripherals can be powered down - as long as the new application powers up peripherals that it uses, they will then be in a de-init state. (If this can not be assumed, you could power all peripherals down and them back up since this is like reseting each peripheral).

And mask all interrupts in the interrupt controller.

Regards

Mark

---

[TomE · Accepted solution]

> Thank you Mark, can you elaborate how to power down peripherals?

"Chapter 10 Power management" in the reference manual is the obvious place to start.

This chip has:

10.2.1 Peripheral Power Management Registers (PPMRH, PPMRL)

They don't power down and reset the peripherals though. They only allow the clocks to be stopped.

Do not simply "stop the clocks" on running peripherals. For instance on the MCF5329 LCDC, stopping the clock while the LCDC is in the middle of a DMA cycle locks it up and locks up the whole chip solid. I'd refer you to the following:

10.2.1

NOTE
It is the software’s responsibility to appropriately disable module clocks
using the PPMRx only when a module is completely unused or quiescent.

10.4.1.5 Peripheral Shut Down
Most peripherals may be disabled by software to cease internal clock generation and remain

in a static state. Each peripheral has its own specific disabling sequence (refer to each

peripheral description for further details). A peripheral may be disabled at any time

and remain disabled during any low-power mode of operation.

You should try to write modular drivers for every peripheral. For each one you want both "open()" and "close()" functions, with the "close()" operation being in the main the reverse of what the "open()" function did.

If you're not using the "Soft Reset" for anything, you could use it to transition from the Boot to the Appliction. Have the boot run normally, set up SRAM (or whatever) so the App can run, and then trigger a Soft Reset. When the boot starts again, it can check for the SOFT bit in the RSR, and then bypass what it normally does and run the Application code with a minimum of setup.

Some chips from some manufacturers might have sections that can be powered down and reset simply. This isn't one of them.

Tom

[Leong]

Thanks Tom,

That's a good idea. I think i can use the watchdog stop to trigger a reset that goes into the bootloader and use a sw reset to go to application by checking the rst source at the beginning of the bootloader.

Guoliang

[scifi]

---

TomE wrote:

If you're not using the "Soft Reset" for anything, you could use it to transition from the Boot to the Appliction. Have the boot run normally, set up SRAM (or whatever) so the App can run, and then trigger a Soft Reset. When the boot starts again, it can check for the SOFT bit in the RSR, and then bypass what it normally does and run the Application code with a minimum of setup.

---

Exactly. That's what I normally do. Except I write a magic number into a static variable and check it early in the boot process. It's very easy to implement, and it does the job well.

[Leong]

---

scifi wrote:

---

TomE wrote:

If you're not using the "Soft Reset" for anything, you could use it to transition from the Boot to the Appliction. Have the boot run normally, set up SRAM (or whatever) so the App can run, and then trigger a Soft Reset. When the boot starts again, it can check for the SOFT bit in the RSR, and then bypass what it normally does and run the Application code with a minimum of setup.

---

Exactly. That's what I normally do. Except I write a magic number into a static variable and check it early in the boot process. It's very easy to implement, and it does the job well.

---

Thanks Scifi, so you are using sw reset in different situations and uses a static var in the ram to tell if it is after a successful boot? then this ram var is cleared in the application?

Regards

Leong

[scifi]

---

Leong wrote:

Thanks Scifi, so you are using sw reset in different situations and uses a static var in the ram to tell if it is after a successful boot? then this ram var is cleared in the application?

---

The static variable is defined in the bootloader. If the bootloader wants to launch the main application, it writes the magic number into the variable and performs a software reset. Once the bootloader is started, it checks the contents of the variable early (before static variables are zeroed and peripherals are initialized). If the magic number is found, the variable is cleared and the main application is launched.

[TomE]

> If the bootloader wants to launch the main application, it writes the magic number into

> the variable and performs a software reset.

There's nothing in the data sheet or the design of the chip that guarantees the contents of the SRAM after power up. It is possible (but unlikely) that SRAM in one unit might wake up with that "magic number" in it. The wider (and weirder) the "magic number" is the less likely this is, but not provably robust. Then there's the possibility of brownouts and voltage dips, which do different things to clean power-ons.

Unlikely? Think about a production run of 400,000 units. In those sort of industries the use of a "magic number" shouldn't make it past a competent design review.

I've worked with CPU chips in the past (NEC) that had a register with a bit in it that indicated "voltage has dropped low enough to corrupt the SRAM". With that feature you could leave all sorts of useful information is SRAM over a reset without having to rely on "magic" or checksums. I've also worked with chips (PXA320) that didn't have a single non-volatile BIT in the whole CPU, possibly for "security reasons".

The "SOFT" bit in the RSR almost does the same thing. If it alone is set you have a guarantee that you can trust a "magic number" in SRAM more than you can without that bit.

The "Processor Expert" products provide peripheral startup code. It would be useful if they also provided working shutdown code as well - does anyone know if they do?

Tom