This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM437X debuger hangs/crashes

We continue to have serious problems with CCS debug sessions that don't start properly or don't reconnect properly to our AM437X board.  I suspect this is related to the CCS support for this reasonably new device, hence posting here.  (I also posted to http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/t/383249 and got a helpful workaround but not an actual answer).

Can anyone suggest either ways to diagnose what's wrong, or a timescale for improvements to CCS support for this chip?

We are seriously considering changing to a different vendor's chip for our application, mainly because of our frustration with the CCS debugging tools, but also with the immature state of the "2.0" SDK for the AM437X, which we hadn't fully realised when we initially selected it.  (eg. not having SYS/BIOS AND networking at the same time without doing a porting exercise ourselves).

Thanks in advance for any suggestions,

Gordon

  • Gordon Deane said:
    Can anyone suggest either ways to diagnose what's wrong, or a timescale for improvements to CCS support for this chip?

    While I haven't got a AM437x to investigate, when I started to try and run programs on a Cortex-A9 core in an OMAP4430 the debugging was intermittent in that couldn't always get to main.

    What I found was that the Cortex-A9 in the OMAP4430 after a system reset starts in Thumb mode, whereas the run time library start-up code assumes the Cortex-A9 starts in ARM mode. When the ARM mode code in the run time library start-up executes with the Cortex-A9 in Thumb mode the code crashes and/or ends up in a boot ROM exception handler. After some crashes the Cortex-A9 got changed to ARM mode which then meant another download attempt in CCS, without and intermediate system reset, worked.

    To work-around this, I added the following code to the OnTargetConnect function in the GEL init scripts:

        GEL_TextOut("CPSR before mode check=%x\n",,,,, CPSR);
        if (CPSR & 0x20)
        {
        	CPSR &=~0x20;
        	GEL_TextOut("Cortex-A9 changed from THUMB to ARM mode\n");
        }
        else
        {
        	GEL_TextOut("Cortex-A9 already in ARM mode\n");
        }
        GEL_TextOut("CPSR after mode check=%x\n",,,,, CPSR);
    

    Where this GEL code changes the Cortex-A9 to ARM mode before the code is set running. With this change the debugging became reliable, and I was able to select "Reset the target on a connect" only on the IcePick_D_0 to get a System Reset when starting a debug session. An example out from the GEL script showing the mode being changed:

    CortexA9_0: GEL Output: CPSR before mode check=0x40000173
    CortexA9_0: GEL Output: Cortex-A9 changed from THUMB to ARM mode
    CortexA9_0: GEL Output: CPSR after mode check=0x40000153
    

    The TI documentation for the AM437x doesn't define if the Cortex-A9 defaults to ARM or Thumb mode after a system reset, so don't know if this is the cause of your problems or not. Therefore, suggest you try modifying the GEL scripts to see what is reported.

  • If the above post doesn't identify the problem, try enabling Debug Server Logging. If you post post a log when debugging works, and when debugging fails, that should help in investigating the reason for the failure.

  • Thanks, Chester. The GEL reports the chip booting up in Thumb mode, and your GEL script seems to fix a crash we were having when loading the program and letting it run to main(). This is progress.

    The CCS "System Reset" still seems to crash the emulator, so there's something going on there, but we do have a workaround for that. (Disconnect, press reset button on board, and reconnect). It's tedious but does seem to be reliable if followed faithfully. "Reset on connect" seems to do the same thing as "System Reset" so we can't use it.

    Thanks also for your suggestion of Debug Server Logging. We'll try to collect that. At the moment we can't say if our issues are caused by CCS , the Blackhawk emulators, or some feature of the AM437X IDK EVM circuit which we have based our board on. We may also try a Spectrum Digital emulator to see if that helps.

    Regards,

    Gordon
  • Interesting discovery in the EM437X_Status.gel shipped for this chip.  It seems the functionality was there, but was disabled.  This could have done with a mention in the release notes.

    The code is:

    //Set the processor to ARM mode and Supervisor mode after a file is loaded, on a 
    //restart or on a reset
    //This will facilitate code loading and debug by putting the processor in a known
    //state
    
    //this function changes certain states of the processor to 
    //allow proper access from CCS.  May not be needed in all situations
    hotmenu AM43xxStartState()
    {
      CPSR &= ~0x20;				 //set to ARM mode
      CPSR = (CPSR & ~0x1F) | 0x13;  //set to privledged mode
      REG_CTXA9_CP15_C1_SCTLR &= ~0x1; //disable MMU
    }
    
    
    DisableOnFileLoaded()
    {
       AM43xxStartState();
    }
    
    DisableOnRestart()
    {
       AM43xxStartState();     
    }
    
    DisableOnReset()
    {
       AM43xxStartState();
       Disable_Watchdog();
    }
    
    DisableOnTargetConnect()
    {
        AM43xxStartState();
        //AM43xx_GP_EVM_Initialization();
        Disable_Watchdog();
    }