Quantcast
Channel: Processors forum - Recent Threads
Viewing all articles
Browse latest Browse all 17527

OMAP-L138: Reliable reset with ICEPICK-C SYSRESET bit

$
0
0

Part Number:OMAP-L138

Hello,

I'm trying to implement a reliable reset procedure for the OMAP-L138 microcontroller without an SRST connection (using OpenOCD). As a result, I'm trying to use the SYSRESET bit of the System Control Register of the ICEPick-C TAP router. The first reset seems fine, but any subsequent attempt fails, and requires a power-on reset. Here are the values of the System Control Register and the Secondary Debug TAP Registers for the ARM and DSP cores, immediately before and after setting the SYSRESET bit :

first reset:

sysctrl:
before: 01003006 (free running tick, general purpose)
after: 01002006 (general purpose)

dsp:
before: 210A0023 (tap power, in reset, power, tap accessible and present)
after: 21080027 (tap power, power, clock, tap accessible and present)

arm:
before: 2218236F (inhibit sleep, tap power, debug connect, tap visible, tap select, force power, power, force active, clock, tap accessible and present)
after: 2218237F (inhibit sleep, tap power, debug connect, tap visible, tap select, force power, power, force active, clock down desired, clock, tap accessible and present)

second reset:

sysctrl:
before: 01003006 (free running tick, general purpose)
after: 01002006 (general purpose)

dsp:
before: 210A0023 (tap power, in reset, power, tap accessible and present)
after: 210A0027 (tap power, in reset, power, clock, tap accessible and present)

arm:
before: 22082367 (tap power, debug connect, tap visible, tap select, force power, power, clock, tap accessible and present)
after: 221A236F (inhibit sleep, tap power, in reset, debug connect, tap visible, tap select, force power, power, force active, clock, tap accessible and present)

The firmware running on the ARM core doesn't use the DSP currently, which explains why the DSP is held in reset at the first reset attempt. Reading the technical manual, it seems the DSP initializes the ARM core so that it runs its ROM boot loader, which is probably why it's not held in reset after the first reset attempt. For some reason I can't figure out, both are held in reset after the second reset attempt.

Thanks for your help.


Viewing all articles
Browse latest Browse all 17527

Trending Articles