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/EK-TM4C1294XL: Problem with pointers?

Part Number: EK-TM4C1294XL

Tool/software: Code Composer Studio

This may be a simple code question, or something else. C is still somewhat uncharted territory for me.

I a trying to read in a 32 bit binary word from GPIO ports. (seems to work)

And then send that word onto ethernet using UDP..

However, there seems to be a problem preparing the data for UDP.

I have this code below:

int main(void)
{
    int Indicator;
    struct pbuf* pdat = pbuf_alloc(PBUF_TRANSPORT,40,PBUF_RAM);
    u32_t data;


    Setup();

    Indicator=0;

    while (1) {
        data=Get32();
        memcpy(pdat->payload,&data,4);

        Indicator^=4;
        GPIOPinWrite(GPIO_PORTN_BASE,GPIO_PIN_2,Indicator);
    }

} 

The code compiles but crashes at run time immediately after the memcpy instruction. Comment that line out, and the rest runs OK.

I suspect something not quite right around my use of the pointers involved, but ...

Below is, what the disassembler tells me:

          main():
00000f44:   2000                movs       r0, #0
00000f46:   B538                push       {r3, r4, r5, r14}
00000f48:   2128                movs       r1, #0x28
00000f4a:   4602                mov        r2, r0
00000f4c:   F7FFFB82            bl         pbuf_alloc
00000f50:   4605                mov        r5, r0
333           Setup();
00000f52:   F7FFF955            bl         Setup
335           Indicator=0;
00000f56:   2400                movs       r4, #0
338               data=Get32();
          $C$L4:
00000f58:   F7FFFFD6            bl         Get32
339               memcpy(pdat->payload,&data,4);
00000f5c:   466A                mov        r2, r13
00000f5e:   6869                ldr        r1, [r5, #4]
338               data=Get32();
00000f60:   9000                str        r0, [r13]
339               memcpy(pdat->payload,&data,4);
00000f62:   6812                ldr        r2, [r2]
00000f64:   4608                mov        r0, r1
00000f66:   6002                str        r2, [r0]
343               GPIOPinWrite(GPIO_PORTN_BASE,GPIO_PIN_2,Indicator);
00000f68:   4803                ldr        r0, [pc, #0xc]
00000f6a:   F0840404            eor        r4, r4, #4
00000f6e:   2104                movs       r1, #4
00000f70:   B2E2                uxtb       r2, r4
00000f72:   F000F93F            bl         GPIOPinWrite
337           while (1) {
00000f76:   E7EF                b          $C$L4

 

The crash happens at address 0x0F68, at which time, the processor jumps to some default FaultISR for an eternal loop.

I know too little (near to nothing, actually) about the assembly code for this processor to fully understand, what is going on. x86 code would have been another matter.

LATEST update:

The instruction at 0x0F66 apparently tries to drop something at the address set aside for ResetISR !!!

That does NOT seem right. There is not any RAM there, I think.

  • Hi,

      The payload element is a pointer. See below. You might want to type cast to pointer like memcpy((u32_t *)pdat->payload,&data,4). Again this is more a C language question than MCU question.

    struct pbuf {
      /** next pbuf in singly linked pbuf chain */
      struct pbuf *next;
    
      /** pointer to the actual data in the buffer */
      void *payload;
    

  • OK, I have now tried your type casting. The result seems to be the same.

    The arrow operator (type cast or not) gives me the starting index of payload (its relative starting address) inside pbuf. In this case 4.

    The program then fetches the address stored at address 0x00004. which incidentally holds the starting address for the ResetISR. Also in flash mem. Here it tries to store my data. Writing to a flash address results in a fault.

    The fun thing about that memcpy statement is, that I have seen it several places here on forum. That is from where I have taken it.

  • Ja Hv said:
    The arrow operator (type cast or not) gives me the starting index of payload (its relative starting address) inside pbuf. In this case 4.

    What is the value of the pbuf pointer shown in the debugger?

    If pbuf is zero (NULL) if means the pbuf_alloc memory allocation failed.

  • Hi,

    Did you configure the GPIO port(N) properly? Not configuring the port properly and then accessing it will result in a fault.

  • It returns zero!

    So my problem is at a completely different location!