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.

ARM 5.1.6 compiler / floating-point UNDERFLOW exception

Other Parts Discussed in Thread: TMS570LS3137

Hi all,

I have to benchmark a compute intensive application that uses a huge amount of data stored in external SDRAM.

I'm using CCS 6.01.00040 for a TMS570LS3137 rev. C on an Hercules Dev. Kit rev. E; the compiler is ARM 5.1.6.

In evaluating an exponential, I fall into an exception case ; having the exception isn't the problem! It's the raising of the exception that gives a prefetch error. After digging into the issue, I see in the library code an STMIA instruction. Is this instruction subject to the STM/LDM bug too ?

I think this is related to my prefetch issue because since I compile the app with the --no_stm flag, all other prefetch issues I had are gone.

In case of a positive answer to the above question, how can I compile the library with the --no_stm flag ? But
after digging in the "no_stm" patch, I'm pretty sure it corrects only memcpy() and memset() functions.

I think there is a more recent release of the ARM compiler. Is there a direct link I can use to get it ? What is the install procedure ?  I cannot use any updater channel because of WEB access security related restrictions.

Thanks for your answer

Marc

FYIFWIW: after initializing the memory (as C language supposes - setting uninitialized vars to 0 and copying the initialization values), the exception is gone ; but I still worry about the prefetch error triggered by the exception code

  • Marc METZGER said:
    I see in the library code an STMIA instruction

    I don't see it.  I checked the floating point routines that are in the RTS library of the TI ARM compiler.  Are you looking at the same library, or some other library?  If you are looking at the same library, please indicate which source file contains the STMIA.

    Marc METZGER said:
    I think there is a more recent release of the ARM compiler. Is there a direct link I can use to get it ? What is the install procedure ?  I cannot use any updater channel because of WEB access security related restrictions.

    Unfortunately, the only way to update the TI ARM compiler is by the update procedures built into CCS.  And they are all web based.

    Thanks and regards,

    -George

  • Hi George,

    Thanks for your answer.

    I'm linking the app with rtsv7R4_T_be_v3D16_eabi.lib library that comes with Code Composer.

    I cannot identify the source file generating the STMIA instruction. I found in following the program flow through the debugger and got a prefetch exception which resulted in an endless loop.

    As I wrote in my first mail, the exception is gone when I correctly do the initialization of the various variables.

    But what will happen when an exception condition appears again in this safety critical app ?
    Are you aware of the "STM bug" affecting the STMIA instruction ?

    I will double check in the asm dump of my app if there is a reference to STMIA.

    Thanks for your help and time.

    Marc
  • You can use the disassembly output to find the location of the STMIA instruction.  From that, you can use the linker map file to work out which object module or library it is from.  If it is from the compiler RTS library, then I can help you directly.  If it is from another library, I am limited to helping you find the team responsible for that library.

    Thanks and regards,

    -George

  • Hi George,

    Thanks for your advice.

    I looked at the asm file produced from the binary with the armdis tool.

    I cannot find an STMIA instruction either. Sorry for the noise.

    But in that listing I see at several places (listed below) an [LMFD|STMFD] R13!, {RegList} construct.

    Knowing that the stack is mapped into external SDRAM, can the above STMFD constructs encounter the device B#04 problem ?

    Thanks for your help.

    Marc

    The following functions use LMFD/STMFD for saving some registers:
    _esmCcmErrorsClear_, __eabi_uldivmod, _dabort, __eabi_idivmod, __eabi_uidivmod
  • In response to another query, SDOWP entry CODEGEN-1299 was filed.  This entry requests that the --no_stm switch be documented.  This includes documenting any related limitations.  Feel free to track it with the SDOWP link below in my signature.

    Marc METZGER said:
    Knowing that the stack is mapped into external SDRAM, can the above STMFD constructs encounter the device B#04 problem ?

    Unfortunately, yes.  The only fix I know is to change all those hand-coded assembly routines in the RTS.  Or at least the ones you know you use.  This should get more clarity in the investigation that comes from CODEGEN-1299.

    Thanks and regards,

    -George