• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 54 subscribers
  • Views 2964 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.

CCS/TMS320C5535: Trouble reading memory block, device core was hung.

Eddie Carrera
Intellectual 820 points
Part Number: TMS320C5535


Tool/software: Code Composer Studio

I'm developing on a TMS320C5535 using the XDS110 debugger, the C5000 chip support library, and Code Composer version: 8.2.0.00007. I enter into my function:

CSL_Status my_Function(CSL_SpiHandle hSpi,
                         Uint16 frame_len,
                         char *ATcmd,
                         Uint8 *pAT_CmdParam,
                         XB_action action)
{
    if ( frame_len < NUM_CONST_BYTES_4 ){
        return (CSL_ESYS_INVPARAMS);
    }

    CSL_Status status = CSL_ESYS_FAIL;
    Uint16 cmdParam_len = frame_len - NUM_CONST_BYTES_4; 
    Uint16 buff_len = frame_len + NUM_CONST_BYTES_4;     
    Uint8 *Tx = (Uint8 *)malloc(sizeof(Uint8) * buff_len);
    memset(Tx, 0x00, sizeof(Uint8) * buff_len); // Init the array

    Uint16 Tx_Idx = 0;
    Uint16 byteCtr;
    . 
    . 
    .

as soon as step into line 7 of this function, I get the following error: 

C55xx: Trouble Reading Memory Block at 0x150005 on Page 1 of Length 0x1: (Error -1143 @ 0x150004) Device core was hung. The debugger has forced the device to a ready state and recovered debug control, but your application's state is now corrupt. You should have limited access to memory and registers, but you may need to reset the device to debug further. (Emulation package 8.0.903.6) 
C55xx: Trouble Reading Memory Block at 0x150005 on Page 1 of Length 0x1: (Error -1143 @ 0x150004) Device core was hung. The debugger has forced the device to a ready state and recovered debug control, but your application's state is now corrupt. You should have limited access to memory and registers, but you may need to reset the device to debug further. (Emulation package 8.0.903.6) 
C55xx: Trouble Reading Memory Block at 0x150006 on Page 1 of Length 0x1: (Error -1143 @ 0x150006) Device core was hung. The debugger has forced the device to a ready state and recovered debug control, but your application's state is now corrupt. You should have limited access to memory and registers, but you may need to reset the device to debug further. (Emulation package 8.0.903.6) 
C55xx: Trouble Reading Memory Block at 0x150007 on Page 1 of Length 0x1: (Error -1143 @ 0x150006) Device core was hung. The debugger has forced the device to a ready state and recovered debug control, but your application's state is now corrupt. You should have limited access to memory and registers, but you may need to reset the device to debug further. (Emulation package 8.0.903.6) 
C55xx: Trouble Reading Memory Block at 0x150008 on Page 1 of Length 0x1: (Error -1143 @ 0x150008) Device core was hung. The debugger has forced the device to a ready state and recovered debug control, but your application's state is now corrupt. You should have limited access to memory and registers, but you may need to reset the device to debug further. (Emulation package 8.0.903.6) 
C55xx: Trouble Reading Memory Block at 0x150009 on Page 1 of Length 0x1: (Error -1143 @ 0x150008) Device core was hung. The debugger has forced the device to a ready state and recovered debug control, but your application's state is now corrupt. You should have limited access to memory and registers, but you may need to reset the device to debug further. (Emulation package 8.0.903.6) 
C55xx: Trouble Reading Memory Block at 0x15000a on Page 1 of Length 0x1: (Error -1143 @ 0x15000A) Device core was hung. The debugger has forced the device to a ready state and recovered debug control, but your application's state is now corrupt. You should have limited access to memory and registers, but you may need to reset the device to debug further. (Emulation package 8.0.903.6) 
C55xx: Trouble Reading Memory Block at 0x15000b on Page 1 of Length 0x1: (Error -1143 @ 0x15000A) Device core was hung. The debugger has forced the device to a ready state and recovered debug control, but your application's state is now corrupt. You should have limited access to memory and registers, but you may need to reset the device to debug further. (Emulation package 8.0.903.6) 
C55xx: Trouble Reading Memory Block at 0x15000c on Page 1 of Length 0x1: (Error -1143 @ 0x15000C) Device core was hung. The debugger has forced the device to a ready state and recovered debug control, but your application's state is now corrupt. You should have limited access to memory and registers, but you may need to reset the device to debug further. (Emulation package 8.0.903.6) 
C55xx: Trouble Reading Memory Block at 0x15000d on Page 1 of Length 0x1: (Error -1143 @ 0x15000C) Device core was hung. The debugger has forced the device to a ready state and recovered debug control, but your application's state is now corrupt. You should have limited access to memory and registers, but you may need to reset the device to debug further. (Emulation package 8.0.903.6) 
C55xx: Trouble Reading Memory Block at 0x15000e on Page 1 of Length 0x1: (Error -1143 @ 0x15000E) Device core was hung. The debugger has forced the device to a ready state and recovered debug control, but your application's state is now corrupt. You should have limited access to memory and registers, but you may need to reset the device to debug further. (Emulation package 8.0.903.6)

I'm not sure why I'm getting this error. I double checked my command linker file and used view->memory allocation to check that there is enough space in RAM and it seems to be okay. I'm not using a GEL file, but I've initialized PPL, LDO, EBSR, and my GPIO registers and have successfully ran other programs using these same initializations, so I don't think initializing my peripherals is the problem either. 

Lastly, I checked the memory map:

Program: Start Addr = 0x0, End Addr = 0x7FFFFFFFFFF...

Data: Start Addr = 0x0, End Addr = 0x7FFFFFFFFFF...

IO: Start Addr = 0x0, End Addr = 0x7FFFFFFFFFF...

I'm not sure if the memory map is the problem, or what GEL file to even use if I need it. Any guidance and advice would be greatly appreciated! 

  • 0
    TI__Guru**** 171309 points
    Hi,

    This behaviour is compatible with a problem in the application itself - namely a problem with stack, a corruption in memory, an inadvertet core reset due to invalid access or instruction, etc.

    Error 1143 is described in greater detail in the reference below (just search for the error number)
    dev.ti.com/.../

    Hope this helps,
    Rafael
  • 0 in reply to desouza
    Intellectual 820 points

    Rafael,

    After replacing lines 14-15:

    Uint8 *Tx = (Uint8 *)malloc(sizeof(Uint8) * buff_len);
memset(Tx, 0x00, sizeof(Uint8) * buff_len); // Init the array
    with:
    Uint8 Tx[4] = {0};

    The error no longer comes up. It seems that the XDS 110 doesn't like malloc(). I have also tried using calloc(), but the same error occurs. I want to keep using malloc instead of an array because I want to manage memory efficiently.

    It's also strange that the error appears on the console as soon as I step into the function, not when I step onto the malloc() line of code. 

    What can I do about this problem?

  • 0 in reply to Eddie Carrera
    TI__Guru**** 171309 points
    Hi,

    The memset and the malloc may throw the processor off if they try to access invalid memory - in case buff_len is too large, heap is too low or the memset is overwriting code.

    This behaviour is highly dependent on the CPU itself (I don't necessarily recall how the C55x behaves), but it was common for the processor to lock itself up if it detected the problem.

    In this particular case, can you check if malloc is returning a valid pointer and not NULL? That would help get further down to the root cause.

    Regards,
    Rafael
  • 0 in reply to desouza
    Intellectual 820 points

    Rafael,

    Thank you for getting back to me and for your help so far! This is how I section off my memory:

    SECTIONS
{
    .cinit            >  DARAM0
	/* Arbitrary assignment of memory segments to .text section.   */
	/* Can be expanded or reduced observing limitations of SPRAA46 */
    .text             >> SARAM0|SARAM1|SARAM2|SARAM3|SARAM4|  	// Executable Code
						 SARAM5|SARAM6|SARAM7|SARAM8|SARAM9

    .bss              > DARAM0|DARAM1|DARAM2|DARAM4				// Global Variables
    .data             > DARAM0|DARAM1|DARAM2|DARAM4
    .stack            > DARAM0|DARAM1|DARAM2|DARAM4
    .sysstack         > DARAM5|DARAM6|DARAM7
    .sysmem           > DARAM5|DARAM6|DARAM7					// Malloc Heap
    .const            > DARAM5|DARAM6|DARAM7					// Initialized Global Varibles
    .switch			  > SARAM10
    .cio              > SARAM13 								// Buffer for stdio functions
    vectors           > SARAM29|SARAM30
}

    and this is how much memory is allocated: 

    I still have plenty if memory left in heap and I don't see why it would be going into an invalid memory location. I also have commented out memset but I still get the error:

        Uint8 *Tx = (Uint8 *)malloc(sizeof(Uint8) * buff_len);
//    memset(Tx, 0x00, sizeof(Uint8) * buff_len); // Init the array

    Also for the sake of testing, my buff_len is only 8 bytes, so I don't think that's allocating too much memory. 

    Unfortunately, by the time I enter the function I start getting (Error -1143 @ 0x150004) and by the time I step into malloc(), the processor locks up and I cannot even get a return value. So there's no way for me to know if malloc is returing a valid pointer. 

    The cheap way to get over this issue would be to just initialize an array instead of using malloc, and I might do that until I can figure out why malloc is causing the system to lock up. 

  • 0 in reply to Eddie Carrera
    TI__Guru**** 171309 points

    Hi,

    Please apologize for the delay; the error you are getting is surely strange. The error -1143 indicates the CPU is hanging on a memory access or a pipeline stall, but I can't really tell for sure.

    One detail I recall is that the C5000 family had some restrictions regarding the allocation of stack, sysstack and sysmem. I  found a discussion where it says the stack and sysstack have to be within 64kB boundary (which yours is), but I vaguely recall the sysmem and the stack needed to be adjacent and have no gaps (unfortunately I couldn't find a reference about these last two). 

    Given you seem to be having issues with the heap, perhaps it is worth a shot to try to put the sysmem, stack and sysstack in the same exclusive memory region(s) (all adjacent) and put everything else in other regions.

    Apart from this, I will have to find some hardware here and test a similar test case. 

    Hope this helps,

    Rafael