TMS570LS0432: _dabort error

Michel B.

Part Number: TMS570LS0432
Other Parts Discussed in Thread: CC3100

Hello,

I am using a TMS570LS0432 microcontroller and sometimes get an "_dabort" error when reading from my memory. In debugging mode, I set a breakpoint in file 'sys_intvecs.asm' where the '_dabort' operation is (see picture).

The first two '_dabort' calls are when the function checkRAMECC(void) in 'system_selftest.c' is excecuted in these two lines:

/* Read the corrupted data to generate double bit error */
ramread = tcramA2bit;
ramread = tcramB2bit;

Here a 'ramErrorFound' is called, but then 'ramErrorReal' is not called, so I assume there is no RAM error. The CPU is restored then and the program goes on (For me this behaviour does not cause any problems, as long as the program continues after the '_dabort' call.

After startup, my program works fine for a few seconds, but then '_dabort' is called again. This time 'noRAMerror' is called and the CPU is restored where it was aborted. The problem is, that the '_dabort' is called again, when the CPU tries to execute the command line again, so it ends up in an infinite loop. The '_dabort' call is caused by this function:

uint32 spiTransmitData8Bit(/* ... */ uint32 length, uint8 * srcbuff) {
    
    uint16 Tx_Data;
    
    // ...

    while(length != 0U) {
        
        // ...

        Tx_Data = *srcbuff;	  <-------- _dabort is called when trying to read scrbuff

        // Send TX_Data ...

        srcbuff++;
        length--;
    }
    
    // ...
}

The strange thing is, that this function is executed successfully a lot of times before the '_dabort' error occurrs.

The last thing I found out is that the pointer 'scrbuff' points to 0x08008000 and the debugger says "Error: memory map prevented reading" (see picture).

Now I want to know:

What does this error message mean?
How can I prevent the '_dabort' call?
Might I be running out of memory?

I already read on these threads:
https://e2e.ti.com/support/microcontrollers/hercules/f/312/t/301090?TMS570-abort-on-startup
https://e2e.ti.com/support/microcontrollers/hercules/f/312/p/301325/1050075

But I could not figure out a solution myself. So I hope someone can help me solving this problem.

Thank you for any answers

Best regards,
Michel

over 7 years ago

0 Michel B. over 7 years ago

Intellectual 300 points

I think something was wrong with my first picture, it should have been this one:

0 Michel B. over 7 years ago in reply to Michel B.

Intellectual 300 points

0 QJ Wang over 7 years ago in reply to Michel B.

TI__Guru**** 198766 points

Hello,

The 0x08008000 is out of the RAM range. LS0432 has 32KB internal SRAM from 0x0800_0000 to 0x0800_7FFF.

0 karthik bharadwaj over 7 years ago

Prodigy 70 points

you didn't post the full code, but I'd check if srcbuff is not null.

at the beginning of spiTransmitData8Bit() try:

```

if (!srcbuff) {

// blink LED

// print error!

return ERR_CODE;

}

0 Michel B. over 7 years ago in reply to QJ Wang

Intellectual 300 points

Hello QJ,

thank you a lot for this information. This explains why my error always occurrs at adress 0x08008000. I just checked the start address of my srcbuff array, it is 0x08007DF4. The array length is 1460, in hex code 0x05B4, so the end address would be 0x080083A8, what is out of RAM range. Then I added this at the beginning of my spiTransmit function:

// If scrbuff is a RAM address
if ((((uint32) srcbuff) & 0xFFFF0000) == 0x08000000) {
    size += length;
    printInt("arrSize: %4d, ", length);
    printInt("addr: 0x%08X, ", srcbuff);
    printInt("total: %7d\r\n", total);
}

This is the end of my output, before the the program is aborted:

arrSize: 1460, addr: 0x08006CD8, total:   23912
arrSize:    4, addr: 0x0800150E, total:   23916
arrSize:    4, addr: 0x08000FB4, total:   23920
arrSize: 1460, addr: 0x0800728C, total:   25380
arrSize:    4, addr: 0x0800150E, total:   25384
arrSize:    4, addr: 0x08000FB4, total:   25388
arrSize: 1460, addr: 0x08007840, total:   26848
arrSize:    4, addr: 0x0800150E, total:   26852
arrSize:    4, addr: 0x08000FB4, total:   26856
arrSize: 1460, addr: 0x08007DF4, total:   28316

It seems that memory for arrays with a small size is allocated somewhere at the beginning of the RAM. But memory for lange arrays is allocated at the end of the RAM with an continously increasing address. If you subtract the large array's adresses you'll always get 0x05B4, what is 1460 in decimal respectively the large array's size in bytes (e.g. 0x08007DF4 - 0x08007840 = 0x05B4). So there is obviously a problem with freeing the allocated memory. I tried to call the free() function at the end of the SPI transmit function:

uint32 spiTransmitData8Bit(/* ... */ uint32 length, uint8 * srcbuff) {
    
    uint16 Tx_Data;
    uint8 *startAddress = srcbuff;
    
    // ...

    while(length != 0U) {
        
        // ...

        Tx_Data = *srcbuff;   <-------- _dabort is called when trying to read scrbuff

        // Send TX_Data ...

        srcbuff++;
        length--;
    }
    
    // ...

    free(startAddress);
}

But the addresses still increase until '_dabort' is called. I know you can only free memory that was allocated with malloc before.

So now I have to explain the background of what I am doing: I want to use the TMS570 with a CC3100 Wifi module. The TMS570 receives CAN messages and stores them in a buffer via interrupt (buffer size is 1400 bytes). In my main loop it sends all new received CAN messages on the Wifi with a TCP protocol. Simply said I'm engeneering a CAN to Wifi adapter. The communication between TMS570 and CC3100 is done via SPI. The CC3100 driver software generates SPI messages for the Wifi module, which are sent with the spiTransmit() function. So what I am suggesting now is that the CC3100 driver software does not free its allocated memory. Since I did not program this driver myself (I only ported it by editing user.h file), I did not understand in which code line it is allocating memory and why it does not free its allocated memory. I tried uncommenting the '#define SL_MEMORY_MGMT_DYNAMIC' line in user.h, so the driver should be able to allocate and free memory itself, but it did not help.

Sorry for this information being a little complex. Maybe this belongs to the Simplelink forum. Nevertheless I really hope someone can help me with some more hits.

Thank you for any further answers.

Best regards
Michel

0 Michel B. over 7 years ago in reply to karthik bharadwaj

Intellectual 300 points

Hi Karthik,

thank you for your answer. I left out the rest of the code for a better overview and reduced it to what is relevant for my problem. Since the debugger said the address is 0x08008000, it can't be null. Additionaly I checked if the address is zero, but it wasn't.

Best regards
Michel

0 Michel B. over 7 years ago in reply to Michel B.

Intellectual 300 points

Hello again,

I just found the reason for my problem. The CC3100 driver software wasn't causing the problem. I already wondered there was no error when memory out of RAM range was reserved, but it was not reserved. I simply put a wrong buffer length in my tcpSend function. Because I mixed up two indexes, I calculated a length of -1 as an int32, this negative length was casted to uint16, so the resulting length was 65535. Since the driver software identified this buffer length as to long for a single SPI message, it was split up in many 1460 byte messages. And of course, memory adresses in my spiTransmit() function were increasing continously then. Due to the fact I have used Java programming language for a long time, I didn't think about a negative value being like -1 casted to the maximum value of an unsigned integer (there are no unsigned integers in Java). So I have been on the wrong path for a little, but you live and learn. From now on I'll always check my function arguments!

Best regards
Michel

Arm-based microcontrollers

Arm-based microcontrollers forum

TMS570LS0432: _dabort error