TDA2EXEVM: Resetting the entire SOC

Hi Priyanka,

Global Cold reset bit resets the entire SoC and triggers the boot again.
What check are you doing to see if A15 has been reset?

Regards,
Rishabh

Hi Priyanka,

The PRM_RSTCTRL bits impact the entire SoC. So A15 will also get reset along with IPU2_C0 when you write to this register to perform a global warm or cold reset.

Can you please have a closer look at the A15 state when you are writing to this register from IPU2_C0? You can also describe in detail what you are observing on the A15, if you see otherwise.

Regards,
Piyali

Hi Piyali/Rishabh,

Before resetting on IPU2_C0 using above mentioned register bit(global warm), I am writing a flag in external QSPI flash.

After reset (If both cores are reset), it is expected (in my case )that , software on A15 should start executing , read that pattern and behave accordingly.
But as only IPU2_C0 is resetting, A15 software does not execute.

Also, after IPU2_C0 reset using register, if I give power on reset (i.e. turn off and on the power supply), A15 software gets control and starts executing as per expectations.

Let me know what can be done to reset A15 as well using register.


Thanks and Reagrds,
Priyanka Zadge

Hi Priyanka,

Where do you see the A15 is after the warm reset? Is it at the same PC location as before the warm reset? Are you printing anything from the A15 UART logs to know if A15 is reading the flash memory or not?

Regards,
Piyali

Hello,

This part of testing is done in stand-alone mode, software are flashed using flash_writer provided by TI and using the Boot-loader developed by KPIT.
Using Boot-loader, software which needs to execute on IPU2_C0 is flashed in external flash.

To observe the behavior of cores in Debug mode in CCS, following procedure is performed:
1. Connected A15 core, loaded scripts.
2.Connected IPU1_C0, using flash_writer Downloaded boot-loader software.
3.Paused the execution on IPU1_c0
4.connected IPU2_C0, loaded .elf file on core
5.Put A15 in running
6.Put IPU2_C0 in running
7.After reset part execution on IPU2_c0 software, Console shows: Unable to connect to DAP
8. Debug window shows IPU2_C0 suspended, But A15 core, shows running.

Let me know, if any step is missed or need to correct.

Thanks,
Priyanka Z

Priyanka,

Before step 7 can you note what is the PC value of A15 before the device is reset.
After step 8, can you halt the A15 and check if the A15 is at the same point.

Also, if will help to keep some UART console prints from the A15 to see if the A15 again reaches the beginning of main from the ROM running on A15.

Thanks and Regards,
Piyali

Hi Piyali,

In the steps mentioned above, step 6 was performed then step 5.
Also, after step 8, in debug window,
both IPU2_C0 and A15 are shown as disconnected and running.
In this case, unable to check the PC value.

After reset part execution, I am getting below message on console:

{Cortex_M4_IPU2_C0: Unable to determine target status after 20 attempts
Cortex_M4_IPU2_C0: Failed to remove the debug state from the target before disconnecting. There may still be breakpoint op-codes embedded in program memory. It is recommended that you reset the emulator before you connect and reload your program before you continue debugging
CortexA15_0: JTAG Communication Error: (Error -1170 @ 0x0) Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 6.0.576.0)}

UART is not being used for the project.


Regards,
Priyanka

Piyali,

Even I skip the step to put A15 in running mode, same message appears on console.

We have below sofwares on cores:
1.IPU2_C0:Application(while executing sends some periodic CAN frames, which can be seen in CANalyzer window)
2.A15: Bootloader(Sends response to application diagnostic request when control comes to it, can be seen in CANalyzer window)

Using bootloader, we are downloading application in flash, then control is handled to application.

In Stand-alone Mode:
1.when application is executing, periodic CAN frames are observed in CANalyzer.
2.Giving reset command, Periodic frames are stopped for some time as application core goes to reset.

3.If power-on-reset(POR) is not given, again application periodic frames are seen in CANalyzer
OR
3.If POR is given, A15 core software i.e bootloader response is observed in CANalyzer.

This is how, we got to conclusion that, A15 is not resetting through global warm/cold.

As per your comment, global warm/cold bit is resetting SOC.
But as we are getting expected behavior after POR only, can you help us diagnose the root cause.
Is there any change in registers update after POR and global warm/cold reset.

It would be very useful if we could connect theough Web-Ex session.
Please convey the suitable time.

Regards,
Priyanka Zadge

Hi Priyanka,

I may missed but did not find in your posts whether you did try with setting the [1]  RST_GLOBAL_COLD_SW bit of PRM_RSTCTRL register? (i.e. not bit [0]!)

This bit [1] initiates a reset that is equivalent to POR and I do not find an errata/report for any issue with it.

Regards,

Stan

Hi Piyali,

As discussed in other thread for IDLE cores, ROM code enables watchdog and reset happens after around 3 minitues when both A15 and IPU2_C0 enter in endless loop..

It is observed that,

1.When watchdog reset happens, core A15 software gets control and start executing.

2.but when global cold bit of register  PRM_RST is set, A15 software does not get control.

Please help to analyze.Is there any part missed  during global cod reset.

Regards,

Priyanka Zadge

Hi Priyanka,

Do you know the PC address where the A15 is stuck when the cold reset boot is happening?
Another experiment to try would be to try the warm reset bit. This would be to check if the A15 re-boot happens when the PRM_RST warm reset is fired.

Thanks and Regards,
Piyali