TMS320F28234: right shift operations have wrong results

Hello Michael!

I think this is the problem of incorrect work of debugger with ISR-code. It happens. Perhaps if you will place your shift operation into the main program body (beyond some ISR) you will not get this strange result.

Regards,

Igor

Hello Igor,

Igor Gorbachev said:

I think this is the problem of incorrect work of debugger with ISR-code. It happens. If you will place your shift operation into the main program body (beyond some ISR) you will not get this strange result.

Can you explain what you are referring to here by incorrect work of debugger with ISR-code?  ISR code is no different from non-ISR code so far as the device is concerned.  Once you get into an ISR, the C28x has no memory that it is in an ISR.  It just thinks it is executing code.  Also, I'm not sure what the debugger has to do with this.  The bottom line here is the assembly code generated by the compiler will execute the same whether it is in an ISR or non-ISR function.

Regards,

David

Hello, David!

My assumption is based on my experience of working with different compilers exclusively. You are correct from a theoretical point of view, and I would agree with you. But when a similar problem occurs, we can not bury our head in the  theory's sand like an ostriches, because the way to the truth is not the way of a logical formalism but a relentless adherence to the reality of being (Martin Heidegger said this in "What is metaphysics?"). The developers of compilers are not gods but they are artisans like everyone else. They have the right to be wrong and besides no one forbids them to use heuristic algorithms in the development. Unfortunately when certifying software product (any product at all) it is not possible to carry out an exhaustive testing. Testing is done on a set of criteria. Yes, this set of criteria can be very large, but it is not exhaustive, it is sufficient from point of view of certifiers only. Thus we get the product which is workable only with a statistical point of view. And when we see that the certified system is not behaving as it should behave then rationalism gives place to the phenomenology. We can not do anything about it, but we have to live with it and somehow adapt to it, because we need to get our result. And from a rational (not phenomenological) point of view, I agree with you completely.

Thanks,

Regards,

Igor

Hello David and Igor,

thanks for your answers. I now found the error by boiling down the code to simple test cases. The variable y is of type unsigned long pointer. If the address is odd, the value of the next-lower even address is read. But in the watch window, the value of the correct address is shown. So there is definitaly a difference between code and the values shown in the watch window. I have to agree with Igor. I had an unreproducible behaviour of the debugger several times in the past. For exampe, in if-decisions, both the if-action and the else-action seem to be executed when stepping through the code. But by watching the concerning variables, I found out, that only the true action was executed. So the debugger showed something else than what was really happening in the code.

Regards,

Michael

Igor,

before speculating about "metaphysics" and the debugger to have its own life, let's cool down. In most cases it is the programmer that does the mistakes, often by forgetting the basics...

Michael;

in your first post you posted:   x = y >>z . In the last post however you said: "y is unsigned long pointer".  If this is true, then a line, such as x=y>>z; will not be accepted by any C-compiler in this world (only metapysics can help here), it will issue an error message and your code generation is stopped long before the Debugger comes into play.

So if you write the following (wrong) code:

unsigned in x,z=2;

unsigned long * y;

x = y >> z;

The C2000 - compiler will issue "Error 31: expression must have integral type". 

A correct code would be:

unsigned in x,z=2;

unsigned long * y;

unsigned long Y1=12;

y = &Y1;

x = *y >> z;

If you now compile and debug, the expressions window will show the correct value for "*y>>z" = 3;  x=3 and Y1 = 12.

Frank, of course you are right. I just simplified the example in my first post because I thought the error has nothing to do with the pointer. My code is corresponding to the correct one you posted.

Regards,

Michael

Hello Frank!

You have written "In most cases it is the programmer that does the mistakes, often by forgetting the basics..." 

I admit, maybe I got a little excited. The charges against the compiler are the latest thing. This can be done after that when all attempts to find code errors exhausted. But the majority of cases does not mean 100% of cases. The probability of an error of compiler's developer is not zero. And it is not the fact that this error will be detected at the stage of certification tests. So we have to always be alert, accepting the fact that the compiler for us is Kantian "thing-in-itself." Alas, we live in a statistical world, where the logic of Aristotle "yes-no" has given way to the logic of "yes-probably-not" (by the way, Robert Anton Wilson with good sense of humor wrote about it at "Quantum Psychology"). If you remember the Copenhagen's interpretation of quantum mechanics proposed by Heisenberg and Bohr, one is based on a statistical treatment of wave-particle duality. Although Einstein and Schrödinger did not accept this interpretation (Einstein wrote to Niels Bohr: "God does not play dice"). But Schrödinger recognized that the laws of nature, even for macro-objects, work statistically ("What is Life? The Physical Aspect of the Living Cell"). Well ... Too much philosophy ...Sorry if I make you be tired by my verbal diarrhea. Certainly philosophy is not science and philosophy is not ideology. At first glance it seems that it does not have any practical value. But it provides a methodology that allows us to survive in this sandyish  and shifting world.

Thanks,

Regards,

Igor

Hi Guys,

We've had much philosophical debate and lobbying citing Einstein and Shroedinger here.  The bottom line on the problem is that Michael has a pointer to an unsigned long, and he apparently has (somehow) assigned an odd value to the pointer.  This is not allowed on the C28x.  Long values must be even aligned.  The compiler was generating correct code, and the debugger was completely in sync with what was going on in hardware.  User error is to blame for the problem.

Michael Weber1 said:

For example, in if-decisions, both the if-action and the else-action seem to be executed when stepping through the code. But by watching the concerning variables, I found out, that only the true action was executed. So the debugger showed something else than what was really happening in the code.

The debugger is nothing more than a data display mechanism (and it can step, run, halt the device of course).  It reads the registers and memory from the device and displays them on the screen.  It is the user that must interpret what is happening when stepping the code.  Remember that the C28x is NOT executing your C code.  It is executing compiler generated instructions at the assembly level, and there is a sometimes very complex mapping between the C-source and the assembly code.  If you just do C-steps in the debugger and watch the C-source code step, it is easy to be fooled as to what is going on.  But again, this is nothing that the debugger is doing incorrectly.  It is the user who is not using the debugger tool correctly.  You needed to be stepping though the generated assembly code to see what is going on when you encounter strange behavior.

Regards,

David

Hello, David!

In my practice, I had not much time for the analytical understanding of the problems that arise when working with compilers. When there is time pressure, often it  have to follow on empirical way to resolve the problem faster. Thanks for the detailed authoritative explanation. I would really like that the way it is. Thus, in our case, we can distinguish only two reasons:

1 not very correct user's code.
2 incorrect use of the debugger.

I really want to come back on solid ground, which provides C28xx (at least until the next issue, which I would not understand again.) So be it: the user is to blame for his problems himself at this case.

Thanks,

Regards,

Igor

P.S. And the TOYOTA-company is recalling cars again, due to defects in the braking system (a joke).