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.

Memory problem on OMAP-L137 board

Hi,

I'm developing fw in DSP side of the omap development kit with ccs4.

I've developed a procedure that send a UDP packet to a pc-host repeatedly. After some sends the debug stall and if I pause the session I received this message:

 

Trouble Halting Target CPU:
Error 0x00000020/-1202
Error during: Execution,

CPU pipeline is stalled and the CPU is 'not ready'. This means
that the CPU has performed an access which has not
completed, and the CPU is waiting. The target may need to be
reset. The user can choose 'Yes' to force the CPU to be 'ready'.
When this is done, the user will have the ability to examine
the target memory and registers to determine the cause of the
CPU stall. If CPU hang is caused by application and it has been
forced to be 'ready', the CPU should not be run without a reset.

  Yes        - force CPU ready (might corrupt the code)
  Disconnect    - disconnect CCS so that it can be reset
  Retry        - attempt the command again

It could be a problem with memory access?

How can be fixed?

  • Alessandro,

    As per your description it seems the code is causing the debugger to lose control of the CPU state. In this case, I can think of two scenarios:

    - Bus contention. The code that sends the UDP packets may be clashing with the CPU for the same memory region. If the code is using DMA repeatedly to transfer large amounts of data from a memory location and the CPU tries to access the same memory region, a stall may occur and the device is not able to move.

    - Device configuration loss. I've seen this happen in the past where the code is sitting in external memory and a rogue pointer or other software problem writes bad values to the PLL or EMIF configuration registers, causing the CPUto  be halted when trying to access the memory.

    To test them I would try some things:

    - put only the code (or the data) to the internal memory to try to avoid any bus contentions;

    - reduce the data size and rate of the UDP packet sending routine;

    - put code and data in the internal memory if the two options above do not fix the problem. Note that this would probably cause another type of fail, as the undesired loss of configuration indicates some other problem is happening with the software.

    These suggestions suppose there are no other hardware fails occuring, but it is always a good idea to check the power and the JTAG connection/emulator...

    Hope this helps,

    Rafael

  • Tanks Rafael,

    I've tested some thing. I've discovered that the problem is occur when I enable the interrupt on reception configurations in my EMAC init routine. If I only send the UDP packets there is no problem. Here I've reported my EMAC_Init function derived from the example source code of the EVM Board.

    I'm developing on EVM module of OMAP_L137 from spectrum digital with on board jtag emulator.

     

     

    INT16 EMAC_Init(PVOID handle)

    {

    SYSTEM_STRUCT* pSys = handle;

    INT16 i;

    volatile INT32U *pReg;

    EMAC_Desc *pDesc;

    ECTRL_INTCONTROL |= ECTRL_INTCONTROL_C0RXPACEEN_ENABLE;

    ECTRL_C0RXIMAX = 0x01;

    /* Set the START bit in SMI register 0x01 of the switch */

    data[0] = 0x01;

    data[1] = 0x23;

         I2C0_write(0x5f, data, 2);

    /* 0. Reset Ethernet */

        EMAC_SOFTRESET = 1;

        while( EMAC_SOFTRESET != 0 );

         Wait_usec( 100 );

        /* ---------------------------------------------------------------- *

         *  Init PHY / MDIO                                                 *

         * ---------------------------------------------------------------- */

        MDIO_CONTROL = 0x40000020;              // Enable MII interface ( MDIOCLK < 5MHz )

        Wait_usec( 1000 );

        /* Wait for link on ENET_P1 (P9)*/

        while( ( (phy_getReg( 1, 1 ) & 0x4 ) == 0));

        phy_dumpRegs();

        /* ---------------------------------------------------------------- *

         *  Init EMAC                                                       *

         * ---------------------------------------------------------------- */

        /* 1. Disable RX/TX interrupts */

        ECTRL_C0RXEN = 0x00000000;

        ECTRL_C0TXEN = 0x00000000;

        /* 2. Clear the MAC control, receive control, & transmit control. */

        EMAC_MACCONTROL = 0;

        EMAC_RXCONTROL = 0;

        EMAC_TXCONTROL = 0;

        /* 3. Initialize all 16 header descriptor pointers RXnHDP & TXnHDP to zero */

    EMAC_RX0HDP = 0;

    EMAC_RX1HDP = 0;

    EMAC_RX2HDP = 0;

    EMAC_RX3HDP = 0;

    EMAC_RX4HDP = 0;

    EMAC_RX5HDP = 0;

    EMAC_RX6HDP = 0;

    EMAC_RX7HDP = 0;

    EMAC_TX0HDP = 0;

    EMAC_TX1HDP = 0;

    EMAC_TX2HDP = 0;

    EMAC_TX3HDP = 0;

    EMAC_TX4HDP = 0;

    EMAC_TX5HDP = 0;

    EMAC_TX6HDP = 0;

    EMAC_TX7HDP = 0;

        /* 4. Clear all 36 statistics registers by writing 0 */

        pReg = &EMAC_RXGOODFRAMES;

        for ( i = 0 ; i < 36 ; i++ )

            *pReg++ = 0;

        /* 5. Setup the local Ethernet MAC address.  Be sure to program all 8 MAC addresses */

        EMAC_MACINDEX  = 0x00;

        EMAC_MACADDRHI = 0x000E9902;    // Needs to be written only the first time

        EMAC_MACADDRLO = 0xFA30;

        EMAC_MACINDEX  = 0x01;

        EMAC_MACADDRLO = 0xFA30;

        EMAC_MACINDEX  = 0x02;

        EMAC_MACADDRLO = 0xFA30;

        EMAC_MACINDEX  = 0x03;

        EMAC_MACADDRLO = 0xFA30;

        EMAC_MACINDEX  = 0x04;

        EMAC_MACADDRLO = 0xFA30;

        EMAC_MACINDEX  = 0x05;

        EMAC_MACADDRLO = 0xFA30;

        EMAC_MACINDEX  = 0x06;

        EMAC_MACADDRLO = 0xFA30;

        EMAC_MACINDEX  = 0x07;

        EMAC_MACADDRLO = 0xFA30;

        /* 6. Initialize the receive channel N */

        /* 7. No multicast addressing */

        EMAC_MACHASH1 = 0;

        EMAC_MACHASH2 = 0;

        /* 8. Set RX buffer offset to 0.  Valid data always begins on the 1st byte */

        EMAC_RXBUFFEROFFSET = 0;

        /* 9. Enable Unicast RX on channel 0-7 */

        EMAC_RXUNICASTSET = 0xFF;

        /* 10. Setup the RX( M )ulticast ( B )roadcast ( P )romiscuous channel */

        /* Enable multi-cast, broadcast and frames with errors */

        EMAC_RXMBPENABLE = 0x01e02020;

        /* 11. Set the appropriate configuration bits in MACCONTROL (do not set the GMIIEN bit yet). */

        EMAC_MACCONTROL = 0

            | ( 1 << 15 )           // 100MHz RMII

            | ( 0 << 9 )            // Round robin

            | ( 0 << 6 )            // TX pacing disabled

            | ( 0 << 5 )            // GMII RX & TX

            | ( 0 << 4 )            // TX flow disabled

            | ( 0 << 3 )            // RX flow disabled

            | ( 0 << 1 )            // Loopback disabled

            | ( 1 << 0 );           // full duplex

        /* 12. Clear all unused channel interrupt bits */

        EMAC_RXINTMASKCLEAR = 0xFF;

        EMAC_TXINTMASKCLEAR = 0xFF;

        /* 13. Enable the RX & TX channel interrupt bits. */

        EMAC_RXINTMASKSET = 0xFF;

        EMAC_TXINTMASKSET = 0xFF;

        /* Enable Host Error and Statistics interrupts */

        EMAC_MACINTMASKSET = 0

            | ( 1 << 1 )            // Host Error interrupt mask

            | ( 1 << 0 );           // Statistics interrupt mask

        /* 14. Initialize the receive and transmit descriptor list queues. */

        /* 15. Prepare receive by writing a pointer to the head of the receive buffer descriptor list to RXnHDP. */

        EMAC_MACSRCADDRLO = 0x000E9902;   /* bytes 0, 1 */

        EMAC_MACSRCADDRHI = 0xFA30;       /* bytes 2-5 - channel 0 ??? */

    /* Descriptor for the receiving buffer */

    pDesc = (EMAC_Desc *)EMAC_RAM_RCV;   // Ram address 0x01E21FFE for RX,  Ram address 0x01E20000 for TX

    pDesc->pNext = 0;

    pDesc->pBuffer = rcv_data_buffer;

    pDesc->BufOffLen = 1500;

    pDesc->PktFlgLen = EMAC_DSC_FLAG_OWNER;

    EMAC_RX0HDP = ( Uint32 )pDesc;

        /* 16. Enable the RX & TX DMA controllers. Then set GMIIEN */

        EMAC_RXCONTROL = 1;

        EMAC_TXCONTROL = 1;

        EMAC_MACCONTROL |= ( 1 << 5 );

        /* 17. Enable the device interrupt in ECTRL. */

        ECTRL_C0RXEN       = 0x00000001; // Enable receive interrupts on channel 0

        ECTRL_C0TXEN       = 0x00000001; // Enable transmit interrupts on channel 0

     

    /* System Structure Initialization */

    pSys->pRcvPacket = &DataRcv; //Store the address of the receiving flags struct to the field of the system struct

        return 0;

    }

     

    When I enable the pDesc assignments I receive the error. 
    Thanks!!
    Alessandro

     

  • Alessandro,

    Unfortunately I am not very experienced in the OMAPL137 EMAC peripheral to give you a precise assessment about your software.

    Although several software details could cause an interrupt to break the system (improper context save/restore in an assembly routine, nested interrupts, etc), I would try to rule out the most common issue: if you are using DSP/BIOS and all your interrupt routines are managed by the HWI Dispatcher, make sure there is no interrupt keyword in your source code.

    From a system perspective, I imagine that enabling the receive interrupt may be causing a flood of interrupts because of network traffic (broadcast packets, ACKs, etc). I would then try to connect the board to a "quieter" network (a private network with just the two communicating hosts) and, if possible, inspect the traffic using Wireshark. This way you can even check what type of traffic is being sent from the board and see if the other host is replying with invalid packet or ACKs or something else that could be causing a high data rate and consequently "locking" the board.

    I am not sure if this helps, but you can check some additional ideas in the page below.

    http://processors.wiki.ti.com/index.php/DSP_BIOS_Debugging_Tips

    Hope this helps,

    Rafael