Failure connecting to AM437x IDK only when debugging

Hi,

What environment are you using?

Biser,

I am using Windows 7 Professional and Code Composer Studio Version: 6.1.1.00022

Doug

Doug Engel said:

M3_wakeupSS_1: Error connecting to the target: (Error -1266 @ 0x0) Device is held in reset. Take the device out of reset, and retry the operation. (Emulation package 6.0.14.5)

The problem is that CCS is trying to load the program onto the Cortex-M3 processor used for the Wake-up Subsystem, and the Cortex-M3 is held in reset until released by the Cortex-A9 processor.

I assume you want to run the "Hello World" program on the Cortex-A9 processor.

Yes, that's correct. I'm trying to work on the Cortex A9.

What needs to be done to get the Wakeup processor to come out of reset so I can debug the A9 with CCS?

Also, am I correct in thinking the Wakeup processor is running firmware embedded in ROM? There's no way to load custom firmware into the Cortex-M3? That core is not listed on any of the block diagrams of the AM437x, so I would believe it is not available for use.

Thanks for the help.

Doug

I gave the link to wiki.tiprocessors.com/.../Processor_SDK_RTOS_Getting_Started_Guide to my coworker and had him go through the steps to run "Hello World" on the AM437x, and he came up with the same results. The step-by-step instructions are a little bit vague and possibly confused because when you set up the CCS Project, there is no predefined Target for the AM437x or the AM437x IDK, and the directions tell you to use AM33X and EVMAM3358 instead. Later, it says that startup_ARMCA9.s would be created, but when we follow along, startup_ARMCA8.s is all we get.

Later, there is a step that says to "Right Click CortexA9 and connect target." This seems to be where we are going off the rails because we can't find any "CortexA9" on the screen or buried in any views in which to right click.

All we can do is debug at this point, and that seems to cause the failures we have been seeing.

It's not clear that something isn't getting weird because of the way we have to lie anout the target in the first step of the instructions. Is there any chance of getting the AM437x and AM437xIDK added to the choices for CCS project targets? That would probably make this easier.

Thanks.

Doug

I made some progress.

With the target configuration built as per the instructions, I click on the DEBUG icon (F11) and it brings up the "Debug" tab with the various debugger probe connections available. They all come up as (Disconnected: Unknown). At this point I can right click the CortexA9 debug probe and select "Connect Target" I get a long series of messages as the GEL files configure the hardware:




CortexA9: Output: **** AM437x IDK EVM Initialization is in progress ..........
CortexA9: Output: **** Device Type: GP
CortexA9: GEL Output: System input clock is 24MHz
CortexA9: GEL Output: **** AM43xx OPP100 with CLKIN=24MHz is in progress .........
CortexA9: GEL Output: **** Going to Bypass...
CortexA9: GEL Output: **** Bypassed, changing values...
CortexA9: Output: **** Locking PLL
CortexA9: GEL Output: **** MPU PLL locked
CortexA9: GEL Output: **** Core Bypassed
CortexA9: GEL Output: **** Now locking Core...
CortexA9: GEL Output: **** Core locked
CortexA9: GEL Output: **** Calculated PER SD Divisor=4
CortexA9: GEL Output: **** PER DPLL Bypassed
CortexA9: GEL Output: **** PER DPLL Locked
CortexA9: GEL Output: **** Calculated EXTDEV SD Divisor=4
CortexA9: GEL Output: **** EXTDEV DPLL Bypassed
CortexA9: GEL Output: **** EXTDEV DPLL Locked
CortexA9: GEL Output: **** DISP PLL Config is in progress ..........
CortexA9: GEL Output: **** DISP PLL Locked
CortexA9: GEL Output: **** DDR DPLL Bypassed
CortexA9: GEL Output: **** DDR DPLL Locked
CortexA9: GEL Output: **** Setting DDR3 = 400MHz
CortexA9: GEL Output: **** AM43xx OPP100 configuration is done .........
CortexA9: GEL Output: Starting DDR3 configuration...
CortexA9: Output: EMIF PRCM is in progress .......
CortexA9: Output: EMIF PRCM Done
CortexA9: GEL Output: EMIF CLK enabled...
CortexA9: GEL Output: Waiting for VTP Ready .......
CortexA9: GEL Output: VTP is Ready!
CortexA9: GEL Output: VTP controller enabled
CortexA9: GEL Output: Checking if DLL is ready...
CortexA9: GEL Output: DLL is ready
CortexA9: GEL Output: Configuring DDR IOs and Control Module registers...
CortexA9: GEL Output: Configuration of Control Module registers complete
CortexA9: GEL Output: Setting up DDR3 H/W leveling configuration...
CortexA9: GEL Output: Starting EMIF controller configuration...
CortexA9: GEL Output:

DDR3 Hardware leveling complete... Outputing all the leveling results !!!

CortexA9: GEL Output: PHY_STATUS_12=0x07000041
CortexA9: GEL Output: PHY_STATUS_13=0x07000038
CortexA9: GEL Output: PHY_STATUS_14=0x07000052
CortexA9: GEL Output: PHY_STATUS_15=0x0700004D
CortexA9: GEL Output: PHY_STATUS_16=0x00000000
CortexA9: GEL Output: PHY_STATUS_7 =0x00000046
CortexA9: GEL Output: PHY_STATUS_8 =0x00000046
CortexA9: GEL Output: PHY_STATUS_9 =0x00000046
CortexA9: GEL Output: PHY_STATUS_10=0x00000045
CortexA9: GEL Output: PHY_STATUS_11=0x00000000
CortexA9: GEL Output: PHY_STATUS_17=0x03480058
CortexA9: GEL Output: PHY_STATUS_18=0x03DF0058
CortexA9: GEL Output: PHY_STATUS_19=0x039A0063
CortexA9: GEL Output: PHY_STATUS_20=0x034F0063
CortexA9: GEL Output: PHY_STATUS_21=0x00000000
CortexA9: GEL Output: PHY_STATUS_22=0x03080018
CortexA9: GEL Output: PHY_STATUS_23=0x039F0018
CortexA9: GEL Output: PHY_STATUS_24=0x035A0023
CortexA9: GEL Output: PHY_STATUS_25=0x030F0023
CortexA9: GEL Output: PHY_STATUS_26=0x00000000
CortexA9: GEL Output:

DDR3 configuration is complete!!!

CortexA9: GEL Output: Turning on EDMA...
CortexA9: GEL Output: EDMA is turned on...
CortexA9: Output: **** AM437x IDK EVM Initialization is Done ******************

----------

Now, I can click "load" and attempt loading my .out file. Then it fails in a new way:


CortexA9: Trouble Writing Memory Block at 0x8000 on Page 0 of Length 0x3b70: (Error -1065 @ 0x3D5A) Unable to access device memory. Verify that the memory address is in valid memory. If error persists, confirm configuration, power-cycle board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 6.0.14.5)
CortexA9: File Loader: Verification failed: Target failed to write 0x00008000
CortexA9: GEL: File: C:\Users\Doug\workspace_v6_0\Hello_CortexA9\Debug\Hello_CortexA9.out: Load failed.

Doug Engel said:

CortexA9: File Loader: Verification failed: Target failed to write 0x00008000

The problem is that the program is set to load at address 0x8000, which isn't memory in the Cortex-A9 memory map. http://wiki.tiprocessors.com/index.php/Processor_SDK_Bare_Metal_Examples#ARM_Cortex-A9 lists the contents of the AM335x.lds linker command file which should be added to the "hello world" project, to cause the linker to place the program into the correct addresses for the memory on the Cortex-A9.

If there is no linker command file, then I think the linker will default to starting the program at address zero which will cause such load failures.

[I haven't got a AM437x IDK to test the instructions in the referenced Wiki page, so my comments are based upon experience of AM335x devices]

Doug Engel said:

All we can do is debug at this point, and that seems to cause the failures we have been seeing.

Assuming the AM437x is handled in the same way as a AM335x device I think what happens is:

1) When starting a debug session the first time on a project built with the ARM compiler on a AM437x, CCS will display a dialogue asking if you want to load the program into the Cortex-A9 and/or Cortex-M3 processors.

2) The default on the dialogue is that both the Cortex-A9 and Cortex-M3 are selected. If you don't de-select the Cortex-M3 before continuing, then CCS will report a failure to load the program onto the Cortex-M3 (since the Cortex-M3 is being held in reset).

3) On subsequent debug attempts CCS will remember the previous selection about which processors to load the program on. i.e. after the initial failure subsequent debug attempts will fail by trying to load the program on the Cortex-M3 but without prompting you about which processors to load the program on.

4) The selection about which processors to load the program on is stored in the .launches subdirectory of the CCS project. If you delete the .launches subdirectory then when starting the next debug attempt CCS will again display the dialogue which selects which processors to the load the program on. At this point you should be able to select only the Cortex-A9 and avoid the original error.

Doug Engel said:

What needs to be done to get the Wakeup processor to come out of reset so I can debug the A9 with CCS?

To debug the Cortex-A9 there is nothing that needs to be done to get the Wakeup processor to come out of reset. The problem was that CCS was trying to load the program to the Cortex-M3, when you only need the program loaded to the Cortex-A9.

Doug Engel said:

Also, am I correct in thinking the Wakeup processor is running firmware embedded in ROM? There's no way to load custom firmware into the Cortex-M3? That core is not listed on any of the block diagrams of the AM437x, so I would believe it is not available for use.

Assuming the AM437x is similar to the AM335x, then:

a) The Cortex-A9 could load custom firmware into the RAM of the Cortex-M3, and the release the Cortex-M3 from reset in order to run the custom firmware.

b) TI supply their firmware for the Cortex-M3 in object form only to be loaded from the Cortex-A9, and don't document the memory map / peripherals of the Cortex-M3. Thus, it is difficult to write custom firmware for the Cortex-M3.

[e.g see Cortex-M3 memory map details missing from AM335x TRM]

Now we are getting somewhere!!!

I figured out how to configure the linker file in the build settings and it seems to build correctly and now I do not get the error when I load the file.

However, the debugger at this point seems to be stuck and nothing I can do at this time seems to work. I cannot reset the board, I cannot single step, I cannot run. I can hit the "suspend" and I get some disassembly showing the PC stopped at some weird address:

00030088:   EAFFFFFE            b          #0x30088

By the way, I looked at the elf binary output to see if there was anything strange and it is shown below:

[ARM ELF Information]
The data encoding of all data in the object file: 32-bit objects
The ELF header version number: Data encodings ELFDATA2LSB
ELF header version number: 1

Object File type: Executable file

The required architecture: ARM/Thumb Architecture

The object file version: Current version

The virtual address(E_entry): 80000000

The program header table's file offset(E_phoff): 0x34 Bytes

The Section header table's file offset(E_shoff): 0xd428 Bytes

Processor-specific flags associated with the file(E_flags): 0x5000002

The ELF header's size(E_ehsize): 0x34 Bytes

The size of one entry in the file's program header table(E_phentsize): 32 Bytes

The number of entries in the program header table(E_phnum): 2

A section header's size(E_shentsize): 40 Bytes

The number of entries in the section header table(E_shnum): 19

The section header table index of the entry associated with

The section name string table(E_shstrndx): 16

Doug Engel said:

However, the debugger at this point seems to be stuck and nothing I can do at this time seems to work. I cannot reset the board, I cannot single step, I cannot run. I can hit the "suspend" and I get some disassembly showing the PC stopped at some weird address:

00030088:   EAFFFFFE            b          #0x30088

That address is the "Pre-fetch abort exception default handler" ROM exception handler, which is listed in section 5.2.3.1.3 Dead Loops of the AM437x ARM® Cortex™-A9 Processors Technical Reference Manual SPRUHL7D. This means the loaded program has generated a Pre-fetch abort exception, and entered a "dead loop" (infinite loop) which has been set in the in the RAM exception vectors by the boot ROM.

I think the reason for the Pre-fetch abort is that the boot ROM is leaving the Cortex-A9 in Thumb mode, but the downloaded program expected the Cortex-A9 to be in ARM mode. The thread https://e2e.ti.com/support/development_tools/code_composer_studio/f/81/t/401837 mentions that the EM437X_Status.gel file supplied with CCS has the calls to AM43xxStartState() commented out, and contains a suggested modification to the ccsv6\ccs_base\emulation\boards\idk_am437x\gel\AM437x_Status.gel make CCS set Cortex-A9 to ARM mode before downloading the program, which should hopefully prevent your crash.