Compiler does not clear H register so returned result is unpredictable.
Solution to clear H register before using index programing.
Eksample:
unsigned char A;
unsigned char B;
#define LOOKUP = 0xF000
A = LOOKUP[B];
Assembler code.
LDX B;
LDA 0xF000,X
STA A;
Makes an unpredictable result.
Solution.
asm CLRH;
A = LOOKUP[B];
Assembler code.
LDX B;
CLRH;
LDA 0xF000,X
STA A;
Makes right result.
Took a little while to figure that one out because no compiler error was reported.
Hi Jennie,
Been on vacation so haven't looked into it yet. Also got a new desktop so had to set everything up. I will get back to you on your question. Though still look like the problem is there with the missing CLRH in the assembler list file. Anyhow. Can I get the Codewarrior 11.0 in a Linux version for install in Ubuntu because on my new desktop I have dualboot for windows and Ubuntu and would like to do my development under Linux.
Regards
Per Højfeldt
Hi Per,
CodeWarrior for linux supporting was dropped. CW 10.2 for linux is the last version.
CW11 doesn't support linux. the support system:
I suggest you use CW11+windows platform instead. if any code issue with CW11 on windows, let's discuss.
Have a great day,
Jennie Zhang
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Hi Per,
Thank you for contacting us.
To avoid misunderstanding, can you please send us more information:
1. your CW version.
2. demo project
Thanks for your cooperation.
Have a great day,
Jennie Zhang
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Hello Jennie,
The Codewarrior version is 11.0.
I attached the project which is a part of a Lithium-ion project to equalize
battery cells to even level for space/aircraft use.
The problem occurred in the file atd.c in the procedure ReadTemperature();
See attached project. Simple fix with one line of assembler code but
compiler should have done that using the Indexed, 16-Bit Offset (IX2)
format.
Best regards
Per Højfeldt
Hi Per,
I see you attach some C files but not demo project?
Can you please create a demo project thus I can debug it directly ?
Have a great day,
Jennie Zhang
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
P.S
Forgot to say that the unzipped files should be placed in path C:\Battery
Manager\unzipped project for the linker and compiler to look at right path.
Per
Hi
I tried to make a simple demo code on my side. but can't reproduce the issue. I wonder the problem is not on index.
Can you please check my code? I wonder how to modify my demo code to reproduce your problem.
I did the demo because I want to narrow down the problem to the right point.
Jennie Zhang
Hi Jennie
Good morning or what time it is where You are. I'm in Denmark.
Anyhow. I created the error in the project you send me. You can see the
problem in the main.lst if you compile with the different definitions of
CELL_TEMPERATURE. Just set your project up to generate list files in build
setup and right click Output. Add %n.lst in the list output.
Don't know of it's really a compiler error that a subtract of a long from
an int gives the different but wort to know.
Have a great morning.
Per
Hi Per Hojfeldt.
I also wonder the problem may be on data type conversion in MACRO. Because if I don't assign MACRO to uiRawBandgap and uiRawTempValue, there is no error.
Anyway, Good to know the problem got solved. Thanks for the sharing.
Have a great day,
Jennie Zhang
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Hi Jennie
Just a little heads up. I disabled all optimization in the compiler. Made
no different. So it's not the optimizer.
Per
On Fri, May 11, 2018 at 10:30 AM, Per Hojfeldt <perhojfeldt@gmail.com>
Hi Per,
I tested your QD4.zip with ucDummy = (25 - (ulTemp / 33)); But I didn't get wrong result for ucDummy.
Does this affect ucDummy result on your side?
Have a great day,
Jennie Zhang
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Sorry I am on trip this week. I will check your issue once I am back.
Jennie.
Hi Jennie
Yes. Just wonder. I will try to use your demo project and make it without
macros and see of it all come down to the calculation of a long with and
int.
Stay tuned.
Enjoy,
Per.
On Fri, May 11, 2018 at 8:06 AM, ZhangJennie <admin@community.nxp.com>
Hi Jennie
After a couple of beers I found the problem. In the first macro in the file
corrtable.h CELL_TEMP_VOLT return a long. Seem to give problems in second
macro CELL_TEMPERATURE. By casting CELL_TEMP_VOLT to an int everything is
fine and CLRH return in assembler code.
Welcome to the wonderful world of C programming.
Thanks for looking into this strange problem.
I attached the solution.
Beast regards
Per Højfeldt
Hi Per Hojfeldt.
I also wonder the problem may be on data type conversion in MACRO. Because if I don't assign MACRO to uiRawBandgap and uiRawTempValue, there is no error.
Anyway, Good to know the problem got solved. Thanks for the sharing.
Have a great day,
Jennie Zhang
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Hi Jennie
I created a small demo program to recreate the error. Was tough to create
the error in cValue = caValues[ucPtr]; but after a while I found out it's a
macro that remove the CLRH in the assembler code.
I attached the demo project as a zip file and it have to be installed in
C:\Battery manager or you can just add the main.c, corrtable.c, corrtable.h
and the linker file Project.prm to you own project.
By comment out the macro the compiler generate correct code but with the
macro the compiler generate wrong code. Check it in the list file main.lst.
Can be fixed by adding asm CLRH; before cValue = caValues[ucPtr];.
Real weird.
Good luck and best regards
Per Højfeldt
On Thu, May 10, 2018 at 11:49 AM, ZhangJennie <admin@community.nxp.com>
Hi Jenny,
I created a zip file with the whole project so if you unzip the attached
file to your computer you should be able to recompile and take a look at
the atd.c and atd.lst file to see the problem.
If you comment out the line asm CLRH; in the atd.c file and recompile you
can see that the CLRH disappear in the resulting assempler code for cT_Corr
= caTempCorr[ucDummy]; and will create an unknown result.
Tried also instead of asm CLRH; to asm LDHX #0; and CLRH return in the
code. Check it out. Must be some strange compiler error but at least there
is a solution.
Best regards and good luck
Per Højfeldt
I can only attach files and not the whole project folder. Its quit big for
a little processor.
How can I attach the project folder with all the files?
Regards
Per Højfeldt