• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 99 subscribers
  • Views 1538 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

HW_RD_REG32 throws E_dataAbort on AM3359ICE2

Jeffrey Gorchynski
Prodigy 240 points
Other Parts Discussed in Thread: SYSBIOS, AM3359

I've been going through the process of upgrading the AM3359 ICE2 board to use the latest EtherCAT Slave Stack Code (SSC v5.11) which in turn requires an upgrade of SysBIOS.

My program compiles just fine, however when executing the program halts when I try to configure a GPIO pin located in the 'SOC_GPIO_2_REGS' register.  It appears the failing line is in hw_types.h:

static inline uint32_t HW_RD_REG32(uint32_t addr)
{
uint32_t regVal = *(volatile uint32_t *) addr
#ifndef MEM_BARRIER_DISABLE
    asm("    dsb");
#endif
    return (regVal);
}


This is the first time in the program this is called on a GPIO from SOC_GPIO_2_REGS; all calls to this function for a GPIO on SOC_GPIO_1_REGS work fine.

Fault printout:

[CortxA8] 0x481ac134 R8 = 0x00008039
R1 = 0x00000020 R9 = 0x00000000
R2 = 0x00000000 R10 = 0x000000cd
R3 = 0x481ac134 R11 = 0x8004fa74
R4 = 0x80049d10 R12 = 0x00000000
R5 = 0x80035874 SP(R13) = 0x8001a3b4
R6 = 0x00000001 LR(R14) = 0x80049ab4
R7 = 0x8004fc10 PC(R15) = 0x8001a3b4
PSR = 0x8004fa74
DFSR = 0x00001008 IFSR = 0x00000000
DFAR = 0x481ac134 IFAR = 0x00000000
ti.sysbios.family.arm.exc.Exception: line 205: E_dataAbort: pc = 0x8001a3b4, lr = 0x80049ab4.
xdc.runtime.Error.raise: terminating execution

I would guess that the MMU is not being initialized with the 'SOC_GPIO_2_REGS' addresses, however the application calls "SDKMMUInit(applMmuEntries);" early on, and it applMmuEntries appears to contain thew GPIO2 registers...

SYS_MMU_ENTRY applMmuEntries[] = {
    {(void*)0x08000000,SYS_MMU_CACHEABLE|SYS_MMU_BUFFERABLE},  //NOR - bufferable| Cacheable
    {(void*)0x08100000,SYS_MMU_CACHEABLE|SYS_MMU_BUFFERABLE},  //NOR -bufferable| Cacheable
    {(void*)0x08200000,SYS_MMU_CACHEABLE|SYS_MMU_BUFFERABLE},  //NOR - bufferable| Cacheable
    {(void*)0x48300000,0},  //PWM - Non bufferable| Non Cacheable
    {(void*)0x48200000,0},  //INTCPS,MPUSS - Non Bufferable| Non Cacheable
    {(void*)0x48100000,0},  //I2C2,McSPI1,UART3,UART4,UART5, GPIO2,GPIO3,MMC1 - Non bufferable| Non Cacheable
    {(void*)0x48000000,0},  //UART1,UART2,I2C1,McSPI0,McASP0 CFG,McASP1 CFG,DMTIMER,GPIO1 -Non bufferable| Non Cacheable
    {(void*)0x44E00000,0},  //Clock Module, PRM, GPIO0, UART0, I2C0, - Non bufferable| Non Cacheable
    {(void*)0x4A300000,SYS_MMU_SHAREABLE | SYS_MMU_BUFFERABLE},  //PRUSS1 -Bufferable| Non Cacheable | Shareable
    {(void*)0x49000000,0},  //EDMA3 - Non bufferable| Non Cacheable
    {(void*)0x4A000000,0},  //L4 FAST CFG- Non bufferable| Non Cacheable
    {(void*)0x4A100000,0},  //CPSW - Non bufferable| Non Cacheable
    {(void*)0xFFFFFFFF,0xFFFFFFFF}
};

My environment:

Compiler: GNU v4.8.4 (Linaro)
SYS/BIOS Industrial SDK version: 2.1.0.1
Sys/BIOS Version: 6.42.3.35
XDCtools Version: 3.31.2.38_core

Is there anything else necessary to access GPIO pins on 'SOC_GPIO_2_REGS'?

  • 0
    TI__Mastermind 30830 points
    Jeff,

    By default, the SYS/BIOS ti.sysbios.family.arm.a8.Mmu module gets pulled in and manages the MMU.
    The SYS/BIOS Mmu module expects to be in charge and has configured the MMU TTBR0 to point to its MMU table.
    But you mention that your application is calling MMU configuration APIs provided by another library.
    I suspect that the MMU table that this other library is configuring is NOT the MMU being used by the A8.
    I encourage you to configure the Mmu module provided by SYS/BIOS with the MMU table entries you need for your application.

    Alan
  • 0 in reply to Alan DeMars
    Prodigy 240 points

    Hey Alan,

    I had the "Mmu.enableMMU = true;" commented out in the app.cfg file, by adding this back in the program executes just fine with the debugger hooked up...

    Unfortunately when I put the application on an SD card and attempt to boot from that, the same line crashes (configuriong IO on SOC_GPIO_2_REGS).  This only occurs when booting from SD, and does not occur when debugging with a USB connection!

    The initialization code in my project is taken directly from the "ethercat_slave"  example program in SDK 2.1.0.1, which does not use any GPIO outside of SOC_GPIO_0_REGS or SOC_GPIO_1_REGS...

    Are there any additional configuration steps that occur with the debugger that could explain why the "GPIOSetDirMode(gpio->adr, gpio->pin, gpio->direction);" function works only with the CCS debugger, but not when booting the same application from SD?

  • 0 in reply to Jeffrey Gorchynski
    TI__Mastermind 30830 points
    Jeff,

    The behavior sounds like perhaps the GPIO register being accessed hasn't been powered up or given a clock yet?
    Various CCS GEL scripts do a lot of clock enabling and PRCM configuring. You may need to translate a few GEL script commands into C code to execute before the GPIOSerDirMode() function.

    Alan
  • 0 in reply to Jeffrey Gorchynski
    TI__Expert 7360 points

    Hi Alan,

    It seems that the GPIO_2 isn't initialized in your application. Please refer to the API Board_initGPIO(IA_SDK_HOME\board\source\drivers\board_gpio.c). There are a couple of functions that initialize GPIO(important ones PRCMModuleEnable and GPIOModuleEnable).

    Regards,
    Vinesh

  • 0 in reply to Vinesh Balan
    Prodigy 240 points

    Thanks Alan and Vinesh,

    It was indeed the PRCMModuleEnable function that needed to be called first in order to use GPIOs on Register banks #2 and 3.

    Thanks again!