SITARA AM437x IDK & TI RTOS : Software reset

Hello,

Does the issue happen only after running from flash with secondary boot loader? Is it working properly if using CCS?

If you connect a JTAG emulator, do you see where the SW hangs at? Re-program pinmux may cause glitch, and you may have to do a hardware reset to restart the application.

Regards,

Garrett

Thanks Garrett,

How do I bypass the pinmux re-program after the sw reset ?

I am not certain if the application would run properly even after pinmux reprogram is bypassed. It would be good to find out where the application is stuck. and as this is only for the purpose of product testing, using a web based power switch with programmable power cycle time to do hard reset would probably be easier.

Regards,

Garrett

What is the recommended way to do a SW reset than ? OR you want to say that it is not supported ?

Inno,

My recommendation is to make your software reset really more of a "software-initiated hardware reset".  This is much more predictable and repeatable as it will force the entire chip to a known good state.  In fact, if your board is designed such that the nRESETIN_OUT signal is used to reset other devices (PHYs, flash, etc.) then this software-initiated hardware reset can put your entire SYSTEM into a known good state.

This can be done by writing to the PRCM_PRM_RSTCTRL register at address 0x44DF4000. You have a choice between warm reset (bit 0) and cold reset (bit 1).  I suggest using cold reset to get a total reset of everything. It is as simple as this:

#define PRCM_PRM_RSTCTRL (*(volatile unsigned int*)0x44df4000)
PRCM_PRM_RSTCTRL = 2; // cold reset

Best regards,
Brad

thanks for your answer.

is the above code should work on the idkam437x board ?

tried on idmam437x.

sw does not seems that it is restarted (ethercat demo ful)

I don't have that example handy.  Have you checked to see if the MMU mapping is present to map that register?  Often times the MMU mappings are part of the cfg file, but I'm not certain on that specific example.  If you hit that bit in the register it will reset the chip, so the only possible thing that could be getting in the way is the MMU.  There are no other dependencies.

Garrett Ding might know more specifically.

MMU is configured in the am437x_app.cfg as Brad indicated:

/* MMU configuration for PRCM - Non Cacheable | Bufferable : Device */
var peripheralBaseAddr = 0x44D00000;
Mmu.setFirstLevelDescMeta(peripheralBaseAddr, peripheralBaseAddr, peripheralAttrs);

"The MMU translation table is 16KB and manages only the first level descriptor table. Each entry in the table defines the properties of memory areas of size 1MB"

Did you try to use global warm reset? PRCM_PRM_RSTCTRL = 1;

Regards,

Garrett

Hi

I appreciate your help

I tried both options

but so far this method did not work on the idk - unlike the jump to cint_00 , here it does not seems that sw starts

I verified "PRCM_PRM_RSTCTRL = 2;" in the while loop of task1 with CCS, which did reset the device as expected - break the JTAG connection.  

Does your function look like below?

void SWResetCommand(int s16_axis,int s16_sub_index)

{

PRCM_PRM_RSTCTRL = 2; // cold reset

}

You may have to connect a JTAG emulator to find out where the PC register points to.

Regards,

Garrett 

thanks

jtag connection is indeed broken , but if I remove the JTAG and just execute the command , the sw does not 'restarts' ....

Please do the following:

• Run your project in CCS
• Set a breakpoint in that function
• Open a memory window to the same address
• Step over that line of code that writes 2 to the register
• Take a screenshot of the entire CCS window and attach it.