Comparison always true in Target code


#1

Hello to All!

I’m new to Open AT world (but not to embedded world :slight_smile: ).

I’m facing some problems developing my first Open AT application. It is aimed on communicating with external uC (LPC2000 family).

Sample code - small routine having to UUencode portion of data:

u32 lpcb_LoadUUData(ascii *out, ascii *in, u8 cnt)
{
    u8  ptr;
    u32 znaki;
    u32 sum;
    u8  z;
	
	if (!cnt || (cnt > 45))
		return 0;

	*out++ = cnt+32;
	
	sum = 0;
	
	do {
		
		for (ptr=0; ptr<3; ptr++) {
			znaki <<= 8;
			
			if (cnt) {
				z = *in++;
				znaki |= z;
				sum += z;
				cnt--;
			}
		}

		for (ptr=0; ptr<4; ptr++) {	
			z = ((znaki >> (18-6*ptr)) & 0x3F) + 32;
            if (z == 32)
                z = 0x60;
			*out++ = z;
		}
	
	} while (cnt);

	*out = 0;	
	return sum;

}

The problem is that, while it works perfectly when compiled in RTE mode, when compiled and run Target mode, result of (z == 32) comparison is ALWAYS true, no matter what value ‘z’ holds.
I’ve checked this by making some ‘debug output’ through serial port - ‘z’ printed right before comparison shows proper values and printed right after ‘if (…) …’ block it always shows ‘grave accent’ (0x60) character :open_mouth:

Whole LoadUUData function is called from timer handler with ‘in’ pointing to globally declared array and ‘out’ pointing to array declared within timer handler.

I suspect some kind of bug in GCC compiler, although I work with GCC for ARM7 daily and didn’t have such problems yet so it is hard to believe for me :wink:

Any hints why my code is ‘failing’? Thanks in advance for answers!

PS. Open AT 4.24, Open AT Firmware 663, GCC 4.0.1.0, Eclipse 3.2.2, hardware: Q2686.


#2

Try adding some {} for the if section… The version of GCC used might very well have some weird bug…


#3

Didn’t help… :frowning:
Furthermore, adding some code before mentioned ‘if’ section, changing name of ‘z’ variable, changing function input parameters and even changing type(!) of ‘z’ to u32 didn’t help either. Strange…


#4

Is the code you posted exactly copied from your source?
Would you mind posting the exact source of that function, including your debug output calls?


#5

Yes, the code was copy-pasted from Eclipse’s editor :slight_smile:

As for debug output - if you think of mentioned output through serial port, I don’t have it right now. It was something like sprintf(txt, “z=%x”, z) followed by adl_fcmSendData(trace_port_handle, …) etc. As I said, it only showed that ‘z’ was, say, 0x55 before and 0x60 after ‘if’ block.
Furthermore, apart from this ‘debug code’ (which is removed now), I still have view on communication between Q2686 and external ARM uC - and it shows clearly that - no matter what is passed in input buffer - transmitted UUencoded lines contain “M``````````(etc)”, not expected “MZH`@L.$(```J?P12XP8(etc)”.
Ah, one more thing: returned checksum value is correct and it reflects passed input data, so function really gets this data.


#6

If that really is the exact source, copied directly from Eclipse as-is, you should probably check your code better or work around it in case it’s really a compiler problem.

Other notes:
znaki should be initialized before use, even if it shouldn’t change anything for you…
Doublecheck and triplecheck that you don’t have any ; between if (z == 32) and z = 0x60.
Or simply rewrite that part of the code entirely. Go the naive approach without the for-loop if needed…