• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 54 subscribers
  • Views 704 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/CC2564CMSP432BTBLESW: Hard fault and weird single-stepping behavior in debugger with code in SRAM

awu@seantec
Intellectual 270 points

Part Number: CC2564CMSP432BTBLESW
Other Parts Discussed in Thread: CC2564C

Tool/software: Code Composer Studio

I use the MSP432 launchpad 2.0 stacked with a PCB containing CC2564C chip and an audio codec. Software base is the A3DPDemo_SNK from the samples directory. After upgrading to Bluetopia 4.2.1.1 I can connect to the device and everything is working fine.

However, after adding additional functionality the program doesn't fit into MAIN memory, anymore. After studying the TI Linker Command File Primer I moved two object files (A3DPDemo_SNK.obj and btvs.obj) into SRAM_CODE memory range. And by only doing this the MCU runs into a hard fault during initialization of BT stack. Following the instruction given in this post I managed to examine the callstack and function right before the hard fault occurs: HCI_VS_InitializeAfterHCIReset. So I put a breakpoint inside and restarted for debugging. The hard fault occurs after stepping over the call to VS_Update_UART_Baud_Rate(BluetoothStackID, SpecifiedBaudRate). So I stepped into this function. The (shortened) code looks like this:

   if((BluetoothStackID) && (BaudRate) && (BaudRate <= CONTROLLER_MAX_HCI_BAUD_RATE))
   {
      /* Write the Baud Rate.                                           */
...
      ret_val = HCI_Send_Raw_Command(BluetoothStackID, OGF, OCF, sizeof(NonAlignedDWord_t), (Byte_t *)&_BaudRate, &Status, &Length, Buffer, TRUE);
      if((ret_val = MapSendRawResults(ret_val, Status, Length, Buffer)) == 0)
      {
...
         ret_val = HCI_Reconfigure_Driver(BluetoothStackID, FALSE, &(DriverReconfigureData));
      }
   }
   else
      ret_val = BTPS_ERROR_INVALID_PARAMETER;

The debugger steps into the if-clause (correct) and calls HCI_Reconfigure_Driver() at its end. So far so good but after that the weird things are starting:

Debugger steps into else-part and continues execution there! Any further single stepping (using F6) simply seems to follow each and every function/statement from the source file. Reaching the return statement it does NOT return but continues with next function from source code file. I don't get this - looking at the values of variables also produces wrong results. What is happening here?



  • 0
    TI__Guru**** 486221 points

    Hello,

    user5315609 said:
    Debugger steps into else-part and continues execution there! Any further single stepping (using F6) simply seems to follow each and every function/statement from the source file. Reaching the return statement it does NOT return but continues with next function from source code file. I don't get this - looking at the values of variables also produces wrong results. What is happening here?

    It's hard to say without a test case but it sounds like either a) the source file being referenced by the debugger is not the same one used for the build or b) the code is optimized, which would impact debug visibility.

    Can you check the Disassembly view and see if the interleaved source line matches the assembler instructions?

    Thanks

    ki

  • 0 in reply to Ki
    Intellectual 270 points

    This is a real big hit: after switching to Disassembly view I understand why things are happing the way I described:

    What a bummer - I started with original MSP432P401R linker command file, but every code placed in SRAM_CODE memory range evaluates to zero! Here is the original code:

    MEMORY
{
    MAIN       (RX) : origin = 0x00000000, length = 0x00040000
    INFO       (RX) : origin = 0x00200000, length = 0x00004000
    SRAM_CODE  (RWX): origin = 0x01000000, length = 0x00010000
    SRAM_DATA  (RW) : origin = 0x20000000, length = 0x00010000
}

    It looks to me that there is no SRAM at address 0x01000000 as defined in linker command file.

    After checking the content of SRAM_DATA seems to be fine I changed the memory ranges to:

        SRAM_CODE  (RWX): origin = 0x20000000, length = 0x00005000
    SRAM_DATA  (RW) : origin = 0x20005000, length = 0x0000B000

    Now everything is working fine. But what does that mean - is my launchpad damaged? Isn't there supposed to be SRAM at this address?

    And last but not least: why does CCS not warn me when writing to non-existent memory?

    Thank you @Ki for pointing me into the right direction!

  • 0 in reply to awu@seantec
    TI__Guru**** 163255 points

    Looking at the data sheet I don't believe you can place code at 0x20000000.  It is RW but not X.  https://www.ti.com/lit/ds/symlink/msp432p401r.pdf

    Code Zone Memory Map The region from 0x0000_0000 to 0x1FFF_FFFF is defined as the Code zone, and is accessible through the ICODE and DCODE buses of the Cortex-M4 processor and through the system DMA. This region maps the flash, the ROM, and the internal SRAM (permitting optimal single-cycle execution from the SRAM).

    CCS is not going to warn you as the memory does exist.  

    Regards,

    John

  • 0 in reply to JohnS
    Intellectual 270 points

    I see your point and this brings me back to my original issue: I had put the code into SRAM at address 0x0100_0000 (as it supposed to be according to fig. 6-2 in data sheet) but then the debugger evaluates the content of SRAM at this place to zero! Just realized that my screenshot is missing in my posting from 14th of April above so here is the disassembly view copied by hand:

              BD_ADDRToStr():
01000000:   0000                movs       r0, r0
01000002:   0000                movs       r0, r0
01000004:   0000                movs       r0, r0
01000006:   0000                movs       r0, r0
01000008:   0000                movs       r0, r0
0100000a:   0000                movs       r0, r0
 344         BTPS_SprintF((char *)BoardStr, "0x%02X%02X%02X%02X%02X%02X", Board_Address.BD_ADDR5, Board_Address.BD_ADDR4, Board_Address.BD_ADDR3, Board_Address.BD_ADDR2, Board_Address.BD_ADDR1, Board_Address.BD_ADDR0);
0100000c:   0000                movs       r0, r0
0100000e:   0000                movs       r0, r0
01000010:   0000                movs       r0, r0
01000012:   0000                movs       r0, r0
01000014:   0000                movs       r0, r0
01000016:   0000                movs       r0, r0
01000018:   0000                movs       r0, r0
0100001a:   0000                movs       r0, r0
0100001c:   0000                movs       r0, r0
0100001e:   0000                movs       r0, r0
01000020:   0000                movs       r0, r0
01000022:   0000                movs       r0, r0
01000024:   0000                movs       r0, r0
01000026:   0000                movs       r0, r0
 345      }

    After changing the SRAM_CODE address in linker command file to 0x2000_0000 it looks like this:

     343      {
          BD_ADDRToStr():
200000e4:   B403                push       {r0, r1}
200000e6:   B580                push       {r7, r14}
200000e8:   AF02                add        r7, r13, #8
200000ea:   F1AD0D18            sub.w      r13, r13, #0x18
200000ee:   9204                str        r2, [r13, #0x10]
 344         BTPS_SprintF((char *)BoardStr, "0x%02X%02X%02X%02X%02X%02X", Board_Address.BD_ADDR5, Board_Address.BD_ADDR4, Board_Address.BD_ADDR3, Board_Address.BD_ADDR2, Board_Address.BD_ADDR1, Board_Address.BD_ADDR0);
200000f0:   78F8                ldrb       r0, [r7, #3]
200000f2:   9000                str        r0, [r13]
200000f4:   78B8                ldrb       r0, [r7, #2]
200000f6:   9001                str        r0, [r13, #4]
200000f8:   7878                ldrb       r0, [r7, #1]
200000fa:   9002                str        r0, [r13, #8]
200000fc:   7838                ldrb       r0, [r7]
200000fe:   9003                str        r0, [r13, #0xc]
20000100:   793B                ldrb       r3, [r7, #4]
20000102:   797A                ldrb       r2, [r7, #5]
20000104:   9804                ldr        r0, [r13, #0x10]
20000106:   A194                adr        r1, #0x250
20000108:   F002F978            bl         $Tramp$TT$L$PI$$BTPS_SprintF
 345      }

    And even more important: the program is working fine instead of being led into hard fault as if in original linker command file. So what is going wrong when using original memory area at address 0x0100_0000 for SRAM_CODE? Are there any additional parameters (I'm not aware of) inside CCS project which could:

    a) cause my configuration to work even while I put code into non-executable address space

    b) make the original memory mapping to fail as shown in disassembly view?

  • 0 in reply to awu@seantec
    TI__Guru**** 486221 points

    user5315609 said:

    And even more important: the program is working fine instead of being led into hard fault as if in original linker command file. So what is going wrong when using original memory area at address 0x0100_0000 for SRAM_CODE? Are there any additional parameters (I'm not aware of) inside CCS project which could:

    a) cause my configuration to work even while I put code into non-executable address space

    b) make the original memory mapping to fail as shown in disassembly view?

    I'll need to loop in some of the device experts. They can provide more insight.

    Thanks

    ki