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.

RTOS/TMS320C6678: Division by zero bit related

Hi all,

I'm trying to understand the effects of a division by zero on the DSP. According to
my previous post (https://e2e.ti.com/support/embedded/tirtos/f/355/t/573031), there

are three registers (FADCR, FAUCR, FMCR) which should set up a bit when the division by zero happens. In

particular, the INFO bit should be set.

Unfortunately no bit sets up. I inspected every register and I didn't find any changes.

I couldn't notice any bit changes.

Please, can anybody help me understand which bit to read?

Giovambattista Astorino

  • I'm moving this to the device forum.
  • How are you compiling the code. Do you have an assembly function or are you testing this using TI compiler. In TI compiler RTS libraries, I suspect that the divide by zero condition is detected and it will return 255 as you can see from the compiler teams response here:
    e2e.ti.com/.../509287

    Regards,
    Rahul
  • One probably has to recognize that there is no division instruction. This means that it ought to be a library function that performs the division. And in such case you are probably not in position to expect something overly specific. But in any case I can confirm that division by zero flag is set if RCPSP, single-precision reciprocal approximation, instruction is issued with 0 input...

  • This is the code I used for the example:

    /*
     * main.c
     */
    
    #include <stdio.h>
    #include <xdc/std.h>
    #include <xdc/cfg/global.h>
    #include <xdc/runtime/System.h>
    
    
    int main(void) {
        
    	
    	int numerator = 10;
    	/*volatile*/ int denominator = 0;
    	int result=0;
    	result=numerator/denominator;
    	
    	System_printf("Result is %d\n", result);
    	System_flush();
    
    	return 0;
    }
    

    Divide_by_zero_test.cfg

    This is my setup:

    Code Composer Studio  Version: 6.2.0.00050

    C compiler TI compiler v8.1.2

    I compared all the visible register with a comparison tool. The only registers which changed are:

    • Program Counter
    • General purpose registers
    • Timer registers
    • TSR (it seems that an interrupt is blocked but we cannot understand which one)
    • PCIE register

    This is the export of all the registers before the division:

    BeforeDivision.txt

    This is the export of all the registers after the division:

    AfterDivision.txt

    We weren't able to find RCPSP register.

    By the way, the result of the division is 31.

    I still have the following question:

    Which bit in which register should I check in order to verify that a division by zero happened?

  • Oh! It seems to be gross misunderstanding from my side. You originally mentioned FADCR, FAUCR, FMCR, and those are floating-point status/control registers. And I assumed that you are talking about floating-point operations. But presented main.c does integer division. It won't set no floating-point flags, sorry about confusion. No [computational] integer instruction would set any flag. And the only right thing to do under circumstances is to explicitly check that divisor is non-zero. I.e. you should do it in your code

    if (denominator != 0) { result = numerator/denominator; }

    Just in case, RCPSP is a floating-point instruction that is used in floating-point division subroutine, not a register.

  • Correct me if I'm wrong, if I modify the main.c , changing the types (let me say I write float instead of integer), shoul I see any changes in the mentioned registers?
  • Giovambattista Astorino said:
    Correct me if I'm wrong, if I modify the main.c , changing the types (let me say I write float instead of integer), shoul I see any changes in the mentioned registers?

    Even if you see changes it would be inappropriate to rely on it, because I don't think TI makes any promises about which flags does [floating-point] division library subroutine set. In other words if you want predictable behaviour, you have to write own division subroutine in assembly.

    Looking from another angle. Let's say you aim to examine the flag. But how would it be different from checking divisor being zero prior division attempt? It's "if (something) do_something" in either case...