How should one reset an AM437x during a debug session?

Gordon,

I will have to double-check a few things, but upfront I can tell that:

Gordon Deane said:

Just use "restart", which is what the IDK release notes suggest.  This sometimes works, but clearly isn't fully resetting the device to a known state, and sometimes the board init hangs if you re-enter this way.

You are correct. Restart does not reset the board/device. I mostly places the PC at the entry point of your code. In this case, any peripheral/interrupt that is pre-configured from a previous run may get in the way of the regular code execution and disrupt the normal flow.

The various reset options in CCS are dependent on what is available on the device and how they are mapped to the various resets. Additional details are shown in this post.

Per your description of the "System Reset", it seems that CCS is mapping it to a reset mode that also resets the emulation logic. That is why you see the JTAG debugger upset (similarly to the external reset switch).

I still need to confirm what exactly reset is mapped to the CCS "System Reset" menu.

With all the information you showed it seems that 6. is your best bet. To alleviate this, you don't need to terminate the debug session all the time but instead simply disconnect the A9 core (on the Debug view, right-click on the A9 core to see this option), reset and then reconnect. This is a lot quicker than terminate/restart the debugger.

I will try to find out the type of reset and perhaps with some additional insights, but in the meantime please give the connect/disconnect a try.

Regards,

Rafael

Rafael,

Thanks for this, your suggestion has speeded up our debug cycle quite a lot. It's still not ideal, neither as fast nor as smooth as we are used to when debugging other chips.

Did you manage to find out what was going on in CCS?

Thanks,

Gordon

Gordon Deane said:

I've worked with a TMS320C6678 and TMS470AM3359 and in both cases, you could reliably get the SoC inc peripherals back to a "known" state with a System Reset or CPU HW reset followed by a GEL init script.  ("Restart" was never enough).  CPU HW reset isn't offered with this chip, and the System Reset gives

I haven't got an AM4379 to try, but the debug configuration shows the device has an IcePick_D. Therefore, setting the "Reset the target on a connect" only on the IcePick_D_0 may be an option. See Can CCS5.5 be configured to assert a system reset before loading a program for how that was used on an AM3359.

I'm afraid this made the problem worse.  That is, "Reset the target on a connect" frequently caused the device to go into an unresponsive state on connect.  

It appears the "System Reset" from within CCS 6.1 is fundamentally not working for this device.  Asking it to happen on connect isn't fixing that.  The best suggestion you've given so far - the one that works - is to disconnect, press the reset button on the board, then reconnect.

I look forward to this being fixed in some future release of CCS, though if you were able to do it by patching the GEL file or something that would be great.

Thanks,

Gordon

Gordon Deane said:

I'm afraid this made the problem worse.  That is, "Reset the target on a connect" frequently caused the device to go into an unresponsive state on connect.  

What I didn't originally realize was that while asserting a System Reset resets the processor state, e.g. disables the MMU and caches, to allow a program to be reloaded, the problem is that issuing a System Reset causes the processor to continue to run after the reset. If the board is configured such that the boot ROM can find an image to boot, the booted image may then put the processor in a state such that CCS debugger then can't download a program.

There is therefore the possibility of a "race condition" of the time between CCS issuing a System Reset and loading the program, .vs. how quickly the board can load an image (e.g. from flash) when causes the CCS program download to fail.

Gordon Deane said:

I look forward to this being fixed in some future release of CCS, though if you were able to do it by patching the GEL file or something that would be great.

Looking at the GEL files in CCS 6.1.1 noticed that the GEL files for the AM335x and AM437x based boards have been changed to assert a System Reset followed by halting the CPU. e.g. the following is in the OnTargetConnect GEL function in the beagleboneblack.gel:

    GEL_AdvancedReset("System Reset"); // Reset the board to avoid conflicts with program running from NOR/SPI/SD
    GEL_Halt();                        // System Reset leaves the core running. Needs to halt it so memory can be accessed

With the unmodified beagleboneblack.gel file in CCS 6.1.1 I can reliably start a CCS download when the board is already running with the MMU enabled, and configured to boot an image from SD card which has the MMU enabled.

The CCS 6.1.1 idk_am437x.gel file referenced on the Cortex-A9 core for the IDK_AM437X board has the same fix, so I think CCS 6.1.1 should also fix your original problem.

[I don't have a IDK_AM437X so can't test that myself]

Chester,

You are correct; we added this snippet to guarantee that any platform-centric configurations (i.e., with a GEL initialization routine) were in a reproducible state before loading code. This worked well for our testcases (mostly baremetal and MLO code), therefore we decided to release it for both AM335x and AM437x devices. AM572x devices have a different reset architecture that renders System Reset

These updated GEL files are available in the sitara device support package release 1.2.5, which comes standard with CCSv6.1.1 but can be used with previous releases as well. I wouldn't go earlier than 6.0, although v5.5. seems to have worked well but wasn't thoroughly tested.

Regards,
Rafael

Hi Chester

Thanks a lot .I had the same issue for more than a month.now every thing is working fine.

regards
Nima shokouhfar