Memory access

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

Memory access

725件の閲覧回数
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by stl on Wed Dec 08 00:45:36 MST 2010
I'm working on a project using LPC1114. I have a lookup table (const unsigned  char table[256]) that holds precalculated values. However, every time I try to access this table, (e.g. table[index] ) I get a hard fault.

From the disassembly, table is at address 0x0d010001. The hard fault occurs when I run "ldrb r3, [r3, #0]" where r3 holds the address (ie table+index).

Any suggestions on why this happens?
0 件の賞賛
返信
2 返答(返信)

713件の閲覧回数
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by CodeRedSupport on Wed Dec 08 02:24:55 MST 2010
So 0x0d010001 sounds more likely to be 0x100010d0 which is in the LPC1114 RAM. However I would not expect a const array to be placed in RAM at all - I would expect it to be placed into the flash, regardless of whether it is declared as local or global.

But 0x0d010001 is in a reserved block of the memory map - and probably would cause a hard fault if accessed. However I don't see how, using default project settings, you would end up with data being placed at this address.

What value do you actually see in r3 before you execute the LDRB instruction?

How have you created the project - is this a standard LPC1114 project created with the LPCXPresso project wizard (and using the standard autogenerated linker script) - or is this something different.

As domen, says, we really need to see some actual code here- and preferably a buildable example.

Regards,
CodeRedSupport
0 件の賞賛
返信

713件の閲覧回数
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by domen on Wed Dec 08 01:13:59 MST 2010
There's no code to look at. :P

The table address seems just wrong, I'd say linker problems, but that doesn't explain the 1 at the end.
0 件の賞賛
返信