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.

Can't Start Debug Session Sometimes

Other Parts Discussed in Thread: AM3359, SYSBIOS, AM3352

Sometimes when I start a debug session I get the error below.  It happens sometimes and most of the time the debugger works fine.  I usually have to try resetting the board and debug session until it starts to work again.

Using AM3359 ICE_V2 eval board with CCS 6.0.1

Error:

CortxA8: Trouble Writing Memory Block at 0x80000000 on Page 0 of Length 0xf4: (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 5.1.507.0)
CortxA8: GEL: File: C:\Users\sdhunna\Documents\SIL\Software\IoModule\EcSlave\Debug\EcSlave.out: Load failed.
CortxA8: Unable to terminate memory download: NULL buffer pointer at 0x3a9f

  • Moving this to the CCS forum.

  • Sundeep Dhunna said:
    I usually have to try resetting the board and debug session until it starts to work again.

    By default CCS doesn't perform a system reset when starting a debug session, and depending upon the state of the device the download of the program can fail.

    Try setting the "Reset the target on a connect" only on the IcePick_D_0. See Can CCS5.5 be configured to assert a system reset before loading a program for how that was used on an AM3359.

  • Ok, so I tried that and it got my program to hit the main function, however once I started running the program would crash upon trying to init GPIOs.

    [CortxA8] 0x4804c000 R8 = 0x4030cdcc
    R1 = 0x0000001e R9 = 0x4030cdf4
    R2 = 0x00000000 R10 = 0x402f82cd
    R3 = 0x00000001 R11 = 0x00029940
    R4 = 0x4030d008 R12 = 0x00000003
    R5 = 0x00028bf4 SP(R13) = 0x8001bdf8
    R6 = 0x00000001 LR(R14) = 0x40304e2c
    R7 = 0x4030cb7c PC(R15) = 0x8001bdf8
    PSR = 0x4030cb7c
    DFSR = 0x00001008 IFSR = 0x00000000
    DFAR = 0x4804c134 IFAR = 0x00000000
    ti.sysbios.family.arm.exc.Exception: line 190: E_dataAbort: pc = 0x8001bdf8, lr = 0x40304e2c.
    xdc.runtime.Error.raise: terminating execution


    static void loader_exit(void)

    I could not make it stop crashing even after unsetting this option.  I had to make a new CCS workspace, import my project, rebuild SYBIOS config, clean, build and then it ran like it used to.

    I have my debug config set to connect debugger on startup and to autoload program.out to the A8 core.

  • Sundeep Dhunna said:
    DFSR = 0x00001008 IFSR = 0x00000000
    DFAR = 0x4804c134 IFAR = 0x00000000

    Decoding those registers mean that a "precise external abort, nontranslation" (decoding the DFSR register according to http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0344f/Bgbiajai.html) reading from the GPIO_OE register (the address in the DFAR register).

    From reading the ARM documentation I am not entirely clear what can cause a "precise external abort, nontranslation". Maybe something in the SYSBIOS configuration wasn't configuring the MMU correctly.

  • I've been developing using the USB debugger, I just tried copying the build to an SD card and now that also crashes this way.  I started a debug session and only loaded symbols and here are the errors:

    0x4804c000 R8 = 0x8001bdf8
    R1 = 0x0000001e R9 = 0x000000be
    R2 = 0x00000000 R10 = 0x402f82cd
    R3 = 0x00000001 R11 = 0x00029940
    R4 = 0x8001e094 R12 = 0x00000003
    R5 = 0x00000000 SP(R13) = 0x8001bdf8
    R6 = 0x40304d50 LR(R14) = 0x40304e2c
    R7 = 0x40304e2c PC(R15) = 0x8001bdf8
    PSR = 0x40304e2c
    DFSR = 0x00001008 IFSR = 0x00000000
    DFAR = 0x4804c134 IFAR = 0x00000000
    ti.sysbios.family.arm.exc.Exception: line 190: E_dataAbort: pc = 0x8001bdf8, lr = 0x40304e2c.
    xdc.runtime.Error.raise: terminating execution

    CCS indicates the MMU is On.

  • Sundeep Dhunna said:
    CCS indicates the MMU is On.

    No further investigation:

    1) The MMU setup in SYS/BIOS for Cortex-A8 targets does configure the MMU to give read/write access to the GPIO1 registers (used the RTSC ti.platforms.beaglebone platform). If the MMU doesn't give permission to access an address then the DFSR register after a failed read was 0x00000005 = "translation fault, section".

    2) The reason for getting the "precise external abort, nontranslation" abort on attempting to read the GPIO1 registers is because after a device reset the GPIO1 module is disabled. To enable the GPIO1 module requires writes to the Clock Module to enable the clocks for the GPIO1 module.

    3) I attempted to copy the GPIO1ModuleClkConfig function from the AM335x StarterWare platform/evmskAM335x/gpio.c file into an AM3352 SYS/BIOS project.

    However, calling the GPIO1ModuleClkConfig() results in a "translation fault, section" abort on attempting to access the CM_PER_GPIO1_CLKCTRL register at address 0x44e000ac because the SYS/BIOS MMU (default) configuration hasn't enabled access to the Clock Module Peripheral Registers. Therefore, need to change the SYS/BIOS MMU configuration.

  • Chester Gillon said:
    However, calling the GPIO1ModuleClkConfig() results in a "translation fault, section" abort on attempting to access the CM_PER_GPIO1_CLKCTRL register at address 0x44e000ac because the SYS/BIOS MMU (default) configuration hasn't enabled access to the Clock Module Peripheral Registers.

    The SYS/BIOS MMU configuration by default only maps the peripheral addresses used by SYS/BIOS. If the SYS/BIOS program uses peripherals not managed by SYS/BIOS then you need to add code to the .cfg file to add MMU mappings for the peripherals.

    For a SYS/BIOS program running on a AM3352 which used GPIO3 registers, the sequence to allow the application to use GPIO3 registers the sequence was:

    1) Add the following to the SYS/BIOS .cfg file to add MMU mappings:

    var Mmu = xdc.useModule('ti.sysbios.family.arm.a8.Mmu');
    
    /* Force peripheral section to be NON cacheable strongly-ordered memory */
    var peripheralAttrs = {
        type : Mmu.FirstLevelDesc_SECTION, // SECTION descriptor
        tex: 0,
        bufferable : false,                // bufferable
        cacheable  : false,                // cacheable
        shareable  : false,                // shareable
        noexecute  : true,                 // not executable
    };
    
    /* Configure the MMU to allow access to the Clock Module Peripheral Registers */
    var CMperipheralBaseAddr = 0x44E00000;
    Mmu.setFirstLevelDescMeta(CMperipheralBaseAddr,
                              CMperipheralBaseAddr,
                              peripheralAttrs);
    
    /* Configure the MMU to allow access to the GPIO3 Peripheral Registers */
    var GPIO3peripheralBaseAddr = 0x481AE000; 
    Mmu.setFirstLevelDescMeta(GPIO3peripheralBaseAddr,
                              GPIO3peripheralBaseAddr,
                              peripheralAttrs);
    

    [The SYS/BIOS MMU configuration for the Cortex-A8 MMU uses 1 Mbyte memory areas, so if multiple peripherals are in the same 1 Mbyte area only one mapping is required]

    2) Before accessing the GPIO3 registers enable the clocks for the GPIO3 module, by copying the GPIO3ModuleClkConfig function from StarterWare.

    3) The SYS/BIOS application could then access the GPIO3 registers without getting data aborts.