System reset

Hi Matteo,

I suspect this may be related to your other question on privileged mode access.  When you are running the processor with a halting debug state, the transactions are marked with a debug attribute which gives similar behavior to a privileged transaction.  If your software is in user mode, then writes to privilege mode registers are not likely to be accepted by the hardware.  However, if you run the same in halting debug it may be taken due to the debug attribute added to the transaction.

It would be a good idea to confirm that your task code executing the reset is privileged code.  If not, you should consider executing the reset via a system call to a privileged state.

Regards,
Karl

Hi Karl, thank you for the answer.

So what to do to execute the call in privileged mode?

I haven't found any information about in the RM48 TRM.

Thank you

Hello Matteo,

ARM mode switching is defined in the ARM architecture manual and the Cortex R4 TRM.  A description is not in the RM48 TRM because the IC level implementation cannot change the behavior as defined by ARM.  

There have been previous similar questions - here is an example thread which includes some code you may find helpful.

http://e2e.ti.com/support/microcontrollers/hercules/f/312/p/150918/546222.aspx#546222

Best Regards,

Karl

So the only way to have a software restart pass trought asm code and low level interrupt?

I'm thrilled there's no an easyer way or at least a clear example code in C.

I'm I the only one requiring such functionality?

Hello Matteo,

The ARM architecture has a specific model for operating modes and transition between operating modes.  TI, nor any other ARM partner, can change this behavior.  I am sorry that ARM's architecture is not meeting your expectations.

Given that a system reset is a critical operation, most of our customers require that it only be executable by a system call or operating system task.  Allowing a user task to reset the system would be considered a serious safety issue in most safety concepts.  

Please note the example which I provided includes multiple examples of code to perform just such a change of modes.  Depending on the RTOS you are using, your RTOS provider may introduce additional restrictions or provided specific functions to support system calls as per the RTOS software architecture.

Best Regards,

Karl

Hello Karl,

I'm not using any RTOS. My code is target to an embedded automatic machine in wich the system reset is an operation as any other one. No safety thrills here.

All my code is executed:

- from main thread (sys_main)

- from ISR (by DMA)

- from IP receiving callback.

I have no idea where the separation between user and system code happens.

Which example are you referring to?

Thank you

Hi Matteo,

The thread previously referenced has examples of code which can generate an SVC to change to supervisor mode, which is privileged.  You could use this to have a handler for your system reset function.  SVC allows you to pass an immediate value to the handler, which can then be used by the handler to differentiate between multiple types of service call requests - i.e. SVC need not be only for your system reset function.

I'd suggest that you check the CPSR to determine which mode of operation you are in during each of the stages you note.  I suspect that your main thread is not in a privileged mode.

Regards,

Karl

Hi Karl,

how can I read the CPSR? (I mean: where)

BTW:

- Could I use an error or abort (for example writing to a wrong register) to force a software reset?

- Could I use the Watchdog to force a system reset (for example wring 0 to the downcounter and enabling the watchdog)?

Hi Matteo,

Sorry for late responses, have been out of office this week.

CPSR is one of the basic registers defined by ARM which includes all of the status flags for the processor.  CPSR is a reserved identifier in ARM assembly code and it can be referenced just like r0..r15.

While a watchdog failure could be set up to force a device reset, I'd recommend against it.  My recommendation is to find and correct the base issue in the software.

Regards,

Karl

Matteo,

Like Karl told you, this system register has to be accessed in privilege mode.

I will send you a test code to demonstrate, but can you check something first.

This CPU Reset bit will reset the CPU only when the value of this bit is toggled.
The reset value at power-on is 0.
Your code is Read the bit value and or it with one. This will create CPU Reset.
Now the bit is one, and if you execute your code again, nothing will happen.
You should have:

systemREG1->CPURSTCR ^= 1U;

Please have a try and let me know.

Hi Jean Marc,

Thank you for the suggestion. It'a a step ahead.

systemREG1->CPURSTCR ^= 1U

do something. Actually it locks the CPU, so is received and executed. The problem is that after the execution of the command my software does not restart, the CPU simply remains locked.

The instraction is called inside a ISR, so I think is in privileged mode.

Do the lack of restart can be due to the code (is compiled in "debug") even if the debugger is not actually on? (the USB cable is plugged but the CCS is not in debug mode).

Matteo

Matteo,

I just want to highlight one important point.
systemREG1->CPURSTCR ^= 1U will reset the CPU ONLY. That means, all peripheral, DMA, VIM are still active and able to generate interrupts.

Is it really what you are looking for or you want also the system to be in reset condition?

The CPU will restart execution from the reset vector (0x0000_0000) and you should have in your boot sequence a way to differentiate a cold start from a warm start.
This is done if you use Halcogen startup code.

/*SAFETYMCUSW 139 S MR:13.7 <APPROVED> "Hardware status bit read check" */
else if ((SYS_EXCEPTION & CPU_RESET) !=0U)
{
/* Reset caused due to CPU reset.
CPU reset can be caused by CPU self-test completion, or
by toggling the "CPU RESET" bit of the CPU Reset Control Register. */

/* USER CODE BEGIN (20) */
/* USER CODE END */

/* clear all reset status flags */
SYS_EXCEPTION = CPU_RESET;

/* USER CODE BEGIN (21) */
/* USER CODE END */

As you can see, you have to call your own warm_start routine.

Can you explain what you mean by CPU is locked?

Speaking of CPU locked I mean that it's appear as freezed. No more debug messages, no more response via IP, ecc.

What I need a clean way to completly restart my code. Something like pressing the reset button on the HDK.

Matteo,

So you are not using the correct method. What you have to do is generate a system reset. This is available via the systemREG1->SYSESR register as described here:

This will be similar to pressing the nRST push button. 

I've yet try with:

systemREG1->SYSECR |= 1U << 15;

but the result is the same of the previous (systemREG1->CPURSTCR ^= 1U). The system restart only when the debugger is on. Is I stop the debugger my reset command simply freeze the machine.

Matteo,

When you say "I stop the debugger", you mean you disconnect the target, unplug the usb from the board and cycle power?
You don't have any connection outside of the device on the nRST pin?
By the way, the SYSTEM reset will be visible on the Device nRST pin. So if you use a scope, you should see nRST going low for few cycle when you execute this command.

Is there anyway you can share your project or a part so I can have a look?

Jean-Marc,

when I say stop the debugger I mean simply exit from the debugger mode in CCS. The USB remains connected.

I'm using the HDK so the connections are the ones of the HDK.

There's a way to share my code in private?

Matteo