Software reset causes system freeze but BKPT causes correct reset

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Software reset causes system freeze but BKPT causes correct reset

ソリューションへジャンプ
2,091件の閲覧回数
chris_f
Contributor V

I have some diagnostic code that writes flash when a problem is detected then tries to reset the system on a K10 device.

If I do a SW reset with the following, the system hangs:

unsigned int i;

asm(" CPSID i"); //DisableInterrupts;

asm(" DSB ");

i = SCB_AIRCR;

i &= 0x0000ffff;

SCB_AIRCR = (i | 0x05FA0004);

asm(" DSB ");

asm (" NOP ");

while(1){};

If, instead, I use a BKPT 0xFF, the system resets fine (when not connected to a debugger of course).

I can use the BKPT approach for production code but would like to understand why the SW reset could cause the hang?

ラベル(1)
0 件の賞賛
返信
1 解決策
1,761件の閲覧回数
mjbcswitzerland
Specialist V

Hi Chris

Just do

SCB_AIRCR = 0x05FA0004;

while (1) {}

and you should have no problems.

Regards

Mark

Kinetis: µTasker Kinetis support

For the complete "out-of-the-box" Kinetis experience and faster time to market

元の投稿で解決策を見る

0 件の賞賛
返信
4 返答(返信)
1,762件の閲覧回数
mjbcswitzerland
Specialist V

Hi Chris

Just do

SCB_AIRCR = 0x05FA0004;

while (1) {}

and you should have no problems.

Regards

Mark

Kinetis: µTasker Kinetis support

For the complete "out-of-the-box" Kinetis experience and faster time to market

0 件の賞賛
返信
1,761件の閲覧回数
chris_f
Contributor V

Thanks Mark, I'll try that tomorrow.

I don't recall where the reset code I was using originated.

I can't see the disable interrupts causing the problem.

The DSB (Data Synchronisation Barrier) instruction could conceivably hang.

Do you think that's the problem?

0 件の賞賛
返信
1,761件の閲覧回数
mjbcswitzerland
Specialist V

Chris

The same code is shown in a few other threads reporting difficulties, although I don't see an actual explanation as to why.

The simplified version is also seen sometimes (as solution) and I have used it myself for about 7 years on many Cortex Ms (including Kinetis KE,KV, KL and Ks) without any issues.

At a guess I would suggest that

i &= 0x0000ffff;

is dangerous since the bits 0x0000003 are write-only and if they "were" to read back '1' and not zero the command would be bad.

ARM writes that these bits should be written only with '0' since they are reserved for debug usage and a write with '1' could cause unpredicatable behaviour: ARM Information Center

i &= 0x00000300 would be theoretically correct (to preserve the interrupt priority grouping field) but since you are resetting it is also not really of any relevance.

Regards

Mark

Kinetis: µTasker Kinetis support

For the complete "out-of-the-box" Kinetis experience and faster time to market

1,761件の閲覧回数
chris_f
Contributor V

Thanks again, Mark.

That fixed it.

Chris

0 件の賞賛
返信