LPCXpresso/LPC1114 Toolchain Problem / gcc/linker bug

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

LPCXpresso/LPC1114 Toolchain Problem / gcc/linker bug

1,092件の閲覧回数
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by coolbrian on Tue Apr 02 05:09:01 MST 2013
Hello all,

I have been hunting a rather strange problem and finally came up with a simple snippet to reproduce the problem.

Platform: x86 Ubuntu 12.04
IDE Version: LPCXpresso v5.1.2 [Build 2065]

When the code (at the end of the post) is compiled with Debug configuration, and downloaded to a LPC1114 variant with LPC-Link, the values of all the variables are all messed up.
I disassembled the AXF file and saw:
[INDENT]  _etext = 0x5c4
  val1   = 0x10000000
  val2   = 0x10000001
  ...
[/INDENT]
Therefore, I looked the data at offset 0x5c4 into the bin file and see unknown data at the place.  The expected 0x11223344 is shifted 4 bytes and located at 0x5c8.

Is it a linker script issue due to the usage of 64 bit data?

Thanks in advance.


Brian

---
#include "driver_config.h"
#include "target_config.h"

volatile uint8_t val1 = 0x11;
volatile uint8_t val2 = 0x22;
volatile uint8_t val3 = 0x33;
volatile uint8_t val4 = 0x44;
volatile uint8_t val5 = 0x55;
volatile uint64_t val6 = 0x66554433221100;

int main(void)
{
while (1) {
val1++;
val2++;
val3++;
val4++;
val5++;
val6++;
}
return 0;
}

---
0 件の賞賛
返信
4 返答(返信)

1,068件の閲覧回数
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by coolbrian on Tue Apr 02 21:39:11 MST 2013
Hello CodeRedSupport,

Yes. You are correct that my project is based on the NXP examples included in the LPCXpresso 5.x, which contain faulty linker scripts + startup code combo.  I think that is the cause of the problem.

Switching to the lone CMSISv1 library seems to solve the problem.  The linker script and the C environment setup code are massively different from the faulty ones.

However, the LPC11xx.h header file supplied by the LPCXpresso-shipped CMSISv1 library is wrong.  Some registers offsets are not correct.  I guess it is not being maintained anymore?

Thank you a lot for the pointers.


Brian
0 件の賞賛
返信

1,068件の閲覧回数
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by CodeRedSupport on Tue Apr 02 08:54:36 MST 2013
I can't tell for definite, as you didn't actually export your project - but I suspect that your project is based on some examples that NXP generated back during the lifetime of LPCXpresso 3. Unfortunately NXP have not updated these examples since - which means that odd problems can occasionally crop up due to their vintage.

I would suggest that you try swapping the startup file you currently have within your project with the startup file generated by the LPCXpresso 5 project wizard. Then rebuild and see if this cures the problem.

For some background information here, see:

http://support.code-red-tech.com/CodeRedWiki/MigratingToNewVersion

Regards,
CodeRedSupport.
0 件の賞賛
返信

1,068件の閲覧回数
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by coolbrian on Tue Apr 02 07:27:55 MST 2013
Hello,

Thank you for testing.  I do not know why the code works with your toolchain while it doesn't with mine...

Please see the attached files for the problem that I am after.

Within ResetISR() in the stock startup/cr_startup_lpc11.c, data is copied from Flash starting at &_etext to RAM.
_etext=0x5c4 (blinky.map) while val[1-6] are stored from 0x5c8 and on in blinky.bin.

Actually, Line #279 in blinky.map says the .data section load address is 0x5c8, which is correct.  However, in ResetISR(), initializing data starting from &_etext (=0x5c4) does not seem right.

Please let me know if you need more information.

Thanks.


Brian
0 件の賞賛
返信

1,068件の閲覧回数
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by CodeRedSupport on Tue Apr 02 05:51:07 MST 2013
No problem seen here with your test code. Variables placed in memory as expected, as seen in the map file. And all display and update as expected when debugging.

One thing to watch is that 64bit variables are padded to sit on a 64bit boundary in memory.

What actually is the "strange problem" you are seeing that you produced this test case for??

Regards,
CodeRedSupport
0 件の賞賛
返信