• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 31 subscribers
  • Views 859 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.

CMSIS DSP Library functions' strange behaviour on debug mode.

Fabio Mantelli
Prodigy 50 points
Other Parts Discussed in Thread: HALCOGEN

I am trying to use the CMSIS DPS library provided by TI to do some matrix operations on the RM48L952PGE processor. I included the "Include" folder of the CMSIS library on the compiler include search path and added the ti_math_Cortex_R4_lspf.lib  as a library file on the linker. The project was made using HalCoGen and CCS.


The problem is that I am not getting the right output from the matrix operation functions from the library. When I check the program on debug mode, I notice a very strage behaviour on arm_mat_add_f32 and arm_mat_mult_f32 function calls. When I click on the 'step into' button the program jumps to random lines inside that function. I keep clicking it and It keeps doing that until it jumps to the 'return' line and exits the function.

Other functions work (arm_mat_init_f32) and there is no problem when I use other libraries. 

How can I fix this problem? 

  • 0
    TI__Guru 68950 points

    Fabio

    You may just be seeing what happens a lot with optimized code.

    Are you seeing it 'jump' around with C-Step or ASM-Step?  And are you seeing the Jumps in the c source window or the disassembly window.

    You shouldn't see the device jumping around randomly in the disassembly window - if you see that then I'd start down the path of checking for hardware issues.   I've only seen this once and it was because I had my clock freq set to 2x what hte part was desinged for (by mistake of course!) 

    If it's jumping around in the C window but is well behaved in the assembly window then I'd chalk it up to optimized code and try to understand what the asm code is doing.  The init code probably is simpler and doesn't get optimized as much..

    What input and output are you trying that make you conclude the result is incorrect?

  • 0 in reply to Anthony F. Seely
    Prodigy 50 points

    Yes, the problem on my code was another thing. I'll open a new post for that, but thanks for the quick response.