• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 30 subscribers
  • Views 1250 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.

TMS570 printf - "long double" not recognized

Nathaniel Schlossberg
Prodigy 140 points

Other Parts Discussed in Thread: HALCOGEN

Hi,

I am trying to get the printf() function to work, but I am consistently getting a data abort exception.  (This is on a TMS570 (Cortex R4F with VFPv3D1g floating support). 

I am using the printf function provided in rtsv7R4_t_be_vD16.lib.

The exception is finally thrown in fcvt().  What is disturbing is when I debug the function, I notice that the stack trace for my "long double" argument instead shows "void".  The debugger watch window says the long double value is also unavailable (it is not even associated with any register, and does not have an associated type with it either).  Has anyone come across this issue before?  Could it be the library was built incorrectly, or perhaps I am missing a linker or compiler option?  Is there a problem with my compiler or my hardware handling long double types?  Normal doubles seem to work ok...

Thanks.

-Nate

  • 0
    TI__Mastermind 22375 points

    Nate,

    Thanks for using our forum.

    Do you have in your linker command file the following statement:

       .sysmem : {} > RAM

    All standard IO routine use a section named .sysmem that has to be mapped in RAM.
    The default linker command file does not have this statement.

    If you are using HalCogen, here is an example:

    /*----------------------------------------------------------------------------*/
    /* Section Configuration                                                      */

    SECTIONS
    {
        .intvecs : {} > VECTORS
        .text    : {} > FLASH0 | FLASH1 | FLASH2 | FLASH3
        .const   : {} > FLASH0 | FLASH1 | FLASH2 | FLASH3
        .cinit   : {} > FLASH0 | FLASH1 | FLASH2 | FLASH3
        .pinit   : {} > FLASH0 | FLASH1 | FLASH2 | FLASH3
        .bss     : {} > RAM
        .data    : {} > RAM

    /* USER CODE BEGIN (4) */

      .sysmem : {} > RAM


    /* USER CODE END */
    }

    /* USER CODE BEGIN (5) */
    /* USER CODE END */


    /*----------------------------------------------------------------------------*/
    /* Misc                                                                       */

    /* USER CODE BEGIN (6) */
    /* USER CODE END */

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

    Please have a try and let me know.

  • 0 in reply to Jean-Marc Mifsud
    Prodigy 140 points

    I do have .sysmem allocated to RAM in my linker command file, as shown above.

    My .map file generated by the linker shows it appropriately allocated.  I'm still in the dark as to what is causing this problem.

  • 0 in reply to Nathaniel Schlossberg
    TI__Mastermind 22375 points

    Nate,

    Can you show me the printf syntax you are using to print your long double?

  • 0 in reply to Jean-Marc Mifsud
    Prodigy 140 points

    Hmm ... so I just discovered I am running out of stack space.  That may be the problem.  I think the debugger is just having issues showing long doubles because they are being stored in the coprocessor (D0 and D8 registers).  I see the assembly code is actually manipulating and using those registers even within the code that doesnt work.

    I thought I allocated more stack space, but I am seeing that the stack pointer still starts at 0x80000400 and decrements below 0x08000000 (outside RAM).  My linker map shows I allocated 0x1000 of space to the stack, so I must have missed something since SP still starts at 0x400 above RAM.

     

  • 0 in reply to Nathaniel Schlossberg
    Prodigy 140 points

    fixes to above response:  0x08000400 is where SP is starting, not 0x80000400 :P

    and i meant to say the "failed" code disassembly looks like it is in fact handling the long doubles even though the debugger cannot display them.

    re-iterate, i think it's a SP initialization issue.

  • 0 in reply to Nathaniel Schlossberg
    TI__Mastermind 22375 points

    Are you using Halcogen to generate your startup code?

  • 0 in reply to Jean-Marc Mifsud
    Prodigy 140 points

    I'm sorry, I can't divulge information about my project.  However, stack-size can be used to change the initial SP value.

  • 0 in reply to Nathaniel Schlossberg
    TI__Mastermind 22375 points

    In the linker command file, there is a section to map the stack.
    This is the total stack definition for all the mode.
    For each mode (User, SVC, IRQ....) you have to define the size of the stack.
    Assuming that the CPU is in user mode when the printf routine is called (and causes the stack issue) than you have to increase the size of the user stack.

    Here is an example of stack init done with Halcogen.

    ;-------------------------------------------------------------------------------
    ; Initialize Stack Pointers

        .def     _coreInitStackPointer_
        .asmfunc

    _coreInitStackPointer_

            cps   #17
            ldr   sp,       fiqSp
            cps   #18
            ldr   sp,       irqSp
            cps   #23
            ldr   sp,       abortSp
            cps   #27
            ldr   sp,       undefSp
            cps   #31
            ldr   sp,       userSp
            cps   #19
            ldr   sp,       svcSp
            bx    lr

    userSp  .word 0x08000000+0x00001000
    svcSp   .word 0x08000000+0x00001000+0x00000100
    fiqSp   .word 0x08000000+0x00001000+0x00000100+0x00000100
    irqSp   .word 0x08000000+0x00001000+0x00000100+0x00000100+0x00000100
    abortSp .word 0x08000000+0x00001000+0x00000100+0x00000100+0x00000100+0x00000100
    undefSp .word 0x08000000+0x00001000+0x00000100+0x00000100+0x00000100+0x00000100+0x00000100

        .endasmfunc

    0x1000 bytes are reserved for User/system stack. In my assumption, this is the one to be increased.

    Please let me know if this is helpful and sorry if this is obvious for you. (I don't know what you know...)

  • 0 in reply to Jean-Marc Mifsud
    Prodigy 140 points

    Oh I see! that was actually very useful.  That explains why my SP kept getting dropped down despite my linker command.  What is the point of the --stack_size option in the linker command then, if everything is controled in this asm function as well as the SECTION mapping in the linker command file?