Constant Table not the same when I compare with memory using the Lpc Expresso Debugger

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Constant Table not the same when I compare with memory using the Lpc Expresso Debugger

741 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by kcarolan on Sat Dec 28 10:09:01 MST 2013
I have a table of constants defined as

cosnt unsigned char table[256] = {1,2,3,4,.....254, 255};

The first 36 bytes of the table are correct, then the rest are incorrect.  I only see the problem when I load the code from the debugger or I load the *.axf file from the Program Flash tool in the Lpc Expresso debugger.  If I load the *.hex file through my application everything is correct.
0 Kudos
Reply
2 Replies

731 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by lpcxpresso-support on Mon Dec 30 04:04:48 MST 2013
If you can, please post a project that reproduces the issue. We should then be able to tell you what you have done wrong.
0 Kudos
Reply

731 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by kcarolan on Sat Dec 28 10:25:38 MST 2013
I have determine what cause the problem with the table not generating correctly.  I am implementing firmware upgrade in my application and inorder to update the Flash from an extermal SPI Serial Flash chip I need to execute the routine that reads from the SPI and writes to the Internal Flash out of RAM.  I have been using the statement

__attribute__ ((__section__(".data.ramfunc")))

just before the two routines that need to run out of RAM.  If I remove the statements the tables are correct.  The only problem is I need the __attribute__ ((__section__(".data.ramfunc"))) to make my firmware upgrade work.  The strange thing is if I use the firmware upgrade portion of my applicatation and download the Hex File via the SPI Serial Flash Chip the table is correct and everything works perfect.  I would like to understand the interaction with the debugger.

Thanks, Kevin
0 Kudos
Reply