sprintf with floating points problem

HTrudel said:

I tried casting the float to a int32 and using %d but the value is always 0 (even if the float value is more than 1).

For anybody reading this, I have tried changing the int32 cast to int16 and now I see the integer part of mVoltagePid.Fdb variable.

Seems like a problem with CCS library.

Illegal instruction traps are usually produced when an invalid instruction is decoded. Please refer to section 3.5.2 and 3.6 in the C28x CPU and
Instruction Set Reference Guide, http://www.ti.com/litv/pdf/spru430d

sprintf should work with %f. Is it possible that your stack is overflowing or heap is not big enough? Please check your stack and heap sizes and try increasing them to see if that helps.

Does your program use DSP/BIOS? If so, are you calling sprintf from a SWI or HWI? Certain runtime functions (sprintf is one of them) cannot be called from SWIs or HWIs. This is documented in Appendix A of SPRU625 (C28x DSP/BIOS 5.32 API Reference Guide) http://www.ti.com/litv/pdf/spru625i

Aarti said:

sprintf should work with %f. Is it possible that your stack is overflowing or heap is not big enough? Please check your stack and heap sizes and try increasing them to see if that helps.

I have tried increasing the stack to 0x400 (linker -stack0x400 option) and obtained the same result.  I have tried increasing the heap size to 1000 (linker -heap1000 option) and still obtained the same result.

Aarti said:

Does your program use DSP/BIOS? If so, are you calling sprintf from a SWI or HWI? Certain runtime functions (sprintf is one of them) cannot be called from SWIs or HWIs. This is documented in Appendix A of SPRU625 (C28x DSP/BIOS 5.32 API Reference Guide) http://www.ti.com/litv/pdf/spru625i

I do not used DSP/BIOS.  The sprintf function is called within an infinite loop context (not an interrupt).

Using the assembly windows, I have identified that the DSP crashes at the LRETR instruction of the ltoa function.

Any idea of what I can do next to isolate the cause of this particular behavior?  I am not very familiar with assembly debugging for this DSP...

I'm seeing something similar.  My code is in flash, with the following map info:

                  00339b4c    00000031     rts2800_fpu32.lib : atoi.obj (.text)
                  00339b7d    00000031                       : sprintf.obj (.text)
                  00339bae    0000002e                       : ltoa.obj (.text)
                  00339bdc    0000002a                       : l_div.obj (.text)

sprintf is in .text

the assembly is as follows:

339B7D      sprintf:
339B7D FE0A ADDB       SP,#10
339B7E 88AD MOVZ       AR6,@SP
339B7F 5DAD MOVZ       AR5,@SP
339B80 A84A MOVL       *-SP[10],XAR4
339B81 C54E MOVL       XAR7,*-SP[14]
339B82 DE8A SUBB       XAR6,#10
339B83 5CAD MOVZ       AR4,@SP
339B84 DD8E SUBB       XAR5,#14
339B85 DC88 SUBB       XAR4,#8
339B86 C348 MOVL       *-SP[8],XAR7
339B87 C242 MOVL       *-SP[2],XAR6
339B88 76F3 MOVL       XAR7,#0x339BA8
339B8A 76B3 MOVL       XAR6,#0x339B94
339B8C C344 MOVL       *-SP[4],XAR7
339B8D C246 MOVL       *-SP[6],XAR6
339B8E 7673 LCR        _printfi
339B90 8A4A MOVL       XAR4,*-SP[10]
339B91 FE8A SUBB       SP,#10
339B92 2BC4 MOV        *+XAR4[0],#0
339B93 0006 LRETR     

The routine calls _printfi, which is located at 0x33a038

                 0033a038    0000003c     rts2800_fpu32.lib : _printfi.obj (.econst)

it seems strange to me that this code is in the .econst section, does this seem right?

if I disassemble 0x33a038, I get:

33A038 0000 ITRAP0    
33A039 0000 ITRAP0    
33A03A 0000 ITRAP0    
33A03B 0000 ITRAP0    
33A03C 0000 ITRAP0    
33A03D FFC0 LSR        AL,1
33A03E FFFF ITRAP1    
33A03F 41DF TBIT       *+XAR7[3],#1
33A040 0000 ITRAP0    
33A041 0000 ITRAP0    
33A042 0000 ITRAP0    
33A043 4024 TBIT       @36,#0
33A044 0000 ITRAP0    
33A045 0000 ITRAP0    
33A046 0000 ITRAP0    
33A047 3FF0 MOV        *+XAR0[6],P
33A048 FFFF ITRAP1    

which is gibberish.  So do you think this should be in the .text section instead of .econst?  This is inside the rts2800_fpu32.lib, so I'm not sure I have control over whether it is in .econst, or not.  I'm not sure why it isn't in the .text section, like sprintf.

Any ideas?

Thanks,

Eric

EricM said:

Any ideas?

I just received a reply from TI support and by increasing the stack size to 0x800 (and remapping the .stack section to RAML5), the sprintf does not crash anymore.

That fixed it for me too!

Thanks,

Eric

Hello,

I have got the same trouble with my DSP F2808, how do u solved it exactly ?

I use DSP from RAM with emulator.

Thanks for your answer

Dave

oldev said:

I have got the same trouble with my DSP F2808, how do u solved it exactly ?

By increasing the stack size to 0x800 in the "build properties -> linker" options of CCS.

Additionally, using TI supplied cmd files (in my project 28335_RAM_lnk.cmd), the stack is mapped to RAMM1 which size is only 0x400.  This is why, in order to increase the stack size to 0x800, the stack section has to be remapped to RAML5.

BTW, I am using the F28335 DSC so you have to adapt my solution to your specific F2808 target.

A few helpful hints for people working with C I/O functions:

• Make sure you have a heap defined as the runtime support library will require heap space to function
• Make sure to include the appropriate header file so that you are not making implicitly defined function calls.  This is particularly important for things like printf which is a variable-length argument function.  If you do not include the header file with the prototype then the compiler will guess incorrectly at how things should be put on the stack, i.e. it won't *know* that it's a variable-length argument function.
• If you're doing a printf in particular where you need the output flushed to the screen that also relies on a special CIO breakpoint as mentioned here.
• I've found that terminating the printf statement with \n (new line) will cause the buffer to be flushed.

Thanks to tech support I have found the problem.

I needed to remove the miniPrintfLib from my project because I'm developing with NDK and I need floating point support.  (miniPrintf removed fp)

I think the docs could have been a bit clearer somewhere.

In my case, the .text section became to large to fit into 0x1000 of RAML1 and i got the error: "placement fails for object .text". In order to solve this i commented out the line:

RAML2      : origin = 0x00A000, length = 0x001000

of the 28335_RAM_lnk.cmd, and enlarged the RAML1 in the line above, as:

RAML1      : origin = 0x009000, length = 0x002000

Other steps involved allocating stack to RAML5 instead of RAMM1, including <stdio.h> and setting the -stack to 0x800.

Hi sir,

I have same problem. when my program execution "printk("%f\n",1.234)" , The program can  halt.

so, I modify

RAMM1      : origin = 0x000400, length = 0x000400

to
RAML5      : origin = 0x00D000, length = 0x003000

and stack set 0x800, the problem is solved

I have checked my stack. It's used about 0x300, not overflow.

I try to modify  

.stack     1    0000d000    00000400     UNINITIALIZED  

                   0000d000    00000400     --HOLE-- 

It can work normal.

My question is why use RMM1 same length 0x400 execute sprintf floating point, it can let program holt ???

Attached file is my project good & NG link & map.

4073.F2833X.rar