CodeWarrior for MCU中的主题 Re: CW v10.2 Win7 64-bit Compilation Bug

CW v10.2 Win7 64-bit Compilation Bug

carloscuev — Tue, 17 Apr 2012 11:20:27 GMT

Hello, I'm having a rather weird problem. Im orking on a project in a QB8 and when I add any extra line of code in a specific function the compiles generates bad code for another function that has nothing to do with the first one.

If I leave the first function ( void main_task(void) ) whithout any extra code, the right code for the affected one is:

But if I add the line "battState = CHARGE_ERROR" to " void main_task(void)" the compiler now generates code that makes the CPU fly into another reality:

If instead I add the line "msecTimerExample = 1;" now I got:

I dont know whats happening, the copiler is messing things up. this is a very weird bug.

Any advice?

Thanks.

Re: CW v10.2 Win7 64-bit Compilation Bug

carloscuev — Tue, 17 Apr 2012 11:56:19 GMT

To confirm this bug, I took the a badly compiled *.s19 file, and replaced the incorrect compiled machine code:

93535292965657

to the correct machine code:

960109C700B781

using a nice *.s19 record editor which recalculates the line checksums.

Then I burned the patched *.S19 to the QB8 and it works! code runs good ! Even that specific part of the code which is a tiny Modbus Slave Stack !

Too bad I can't move on with my code if I cannot get to resolve this issue, please help me.

Re: CW v10.2 Win7 64-bit Compilation Bug

BlackNight — Tue, 17 Apr 2012 13:10:08 GMT

yes, that looks weired. What you show is the thing on the target (or in the S19 file). It would be good to see if the problem is in the compiler or in the linker.

Could you try to disassemble that function/module (right click on the source and select 'disassemble').

This will show the code produced by the compiler.

I'm wondering if at this stage it already looks that weired.

Re: CW v10.2 Win7 64-bit Compilation Bug

carloscuev — Tue, 17 Apr 2012 13:29:17 GMT

What I show is in the fist post is in the target, in the second post is a screenshot of the editor where I edited the S19 file.

Clicking disassemble shows me the correct machine code:

Decoder V-5.0.27 Build 11346, Dec 13 2011
Options: -ArgFilemodbusSlave.args -Env"GENPATH=C:/Users/Carlos/workspace/CC-BAT12-G2_QB8_v1.0/Project_Headers;C:\Freescale\CW MCU v10.2\eclipse\../MCU/lib/hc08c/device/src;C:\Freescale\CW MCU v10.2\eclipse\../MCU/lib/hc08c/lib;C:\Freescale\CW MCU v10.2\eclipse\../MCU/lib/hc08c/src;C:\Freescale\CW MCU v10.2\eclipse\../MCU/lib/hc08c/device/include;C:\Freescale\CW MCU v10.2\eclipse\../MCU/lib/hc08c/include;C:\Freescale\CW MCU v10.2\eclipse\../MCU/lib/hc08c/device/asm_include;C:/Users/Carlos/workspace/CC-BAT12-G2_QB8_v1.0/Generated_Code;C:/Users/Carlos/workspace/CC-BAT12-G2_QB8_v1.0/Sources;C:\Users\Carlos\workspace\CC-BAT12-G2_QB8_v1.0\Sources\components" -EnvOBJPATH=. -EnvTEXTPATH=. -OmodbusSlave.lst -ViewHidden -WmsgFob"%f%e:%l:%k:%d %m\n"
Decoding File: 'C:\Users\Carlos\workspace\CC-BAT12-G2_QB8_v1.0\Sources\components\modbusSlave.obj'
File format: ELF/DWARF

DISASSEMBLY OF: '.text' FROM 1572 TO 2018 SIZE 446 (0X1BE)
Opening source file 'C:\Users\Carlos\workspace\CC-BAT12-G2_QB8_v1.0\Sources\components\modbusSlave.c'
36: void modbusSlave_setReadRegisters(uint16 const * const registers[], uint8 length)
modbusSlave_setReadRegisters:
00000000 960000 STHX readRegisters
39: readRegistersLen = length;
00000003 C70000 STA readRegistersLen
40: }
00000006 81 RTS

It's weird that output file and flashed binaries later become erroneous.

Re: CW v10.2 Win7 64-bit Compilation Bug

carloscuev — Tue, 17 Apr 2012 13:35:37 GMT

Function in question is very simple, hence only needs 7 Bytes of flash:

void modbusSlave_setReadRegisters(uint16 const * const registers[], uint8 length)
{
readRegisters = registers;
readRegistersLen = length;
}

I wonder from where does CW takes 0x93535292965657 and replaces the correct machine code: 0x960109C700B781

Re: CW v10.2 Win7 64-bit Compilation Bug

carloscuev — Tue, 17 Apr 2012 13:53:35 GMT

Found bug, is the USBDM Eclipse plugin.

When writing to the target, it writes to 0xE31A the contents that should be in 0xF31A,

Interestingly, the *.S19 is 11,004 bytes when not having the extra line and flashes OK,

Adding the lines results in a filesize of 11,000 (guess due optimizations?) and is when flashes badly

Re: CW v10.2 Win7 64-bit Compilation Bug

BlackNight — Tue, 17 Apr 2012 14:05:56 GMT

So it is the USBDM (to clarify, not the P&E OSBDM)? Can you try it with a P&E cable (if you have one)?

Re: CW v10.2 Win7 64-bit Compilation Bug

carloscuev — Tue, 17 Apr 2012 14:19:24 GMT

Yes PGO's USBDM v4.9.3 Eclipse's Plugin, I've just installed USBDM v4.9.4b along with Eclipse's plugin and problem is solved. I have a P&E cable but is forgotten somewhere in here

The problem was that when flashing within Eclipse, several bytes starting from adress 0xF31A were written into 0xE31A, thats just the least significant bit of the high adress byte being swapped from 0 to 1, anyway, this USBDM bug was happeining just when adding more code, don't really know what is really triggering it.

Sorry for the false alarm, whats should I change the thread subject to? I don't want to raise false ideas.

Re: CW v10.2 Win7 64-bit Compilation Bug

BlackNight — Tue, 17 Apr 2012 14:29:37 GMT

I think the moderator will take care (if necessary at all).

What counts is that the problem is solved :smileyhappy:

Re: CW v10.2 Win7 64-bit Compilation Bug

carloscuev — Tue, 17 Apr 2012 14:39:22 GMT

Ok, thanks. I don't want to scare anyone from a tremendous false bug, the first post could really scare people that don't want to migrate to CW v10, As that Eclipse View (Dissassembly in my Debugger Perspective) gets the flash data via BDM from the target, not from the local files nice detail ! At least we've learned something else!

And in the second post I was modifying the flash data for a const lookup table which is accessed rarely and I didn't detect any flaw haha!