MCUXpresso Program Load Locations

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

MCUXpresso Program Load Locations

2,415 Views
edarrington
Contributor II

I have been using LPCXpresso for several years, since version 7.4, and am current on 8.2.2.  Our application has gotten fairly sophisticated with code running in one of multiple memory blocks.  

I decided to give MCUXpresso a try since it appears that will be NXP's recommended IDE going forward.  My programs compile and link as usual, and the addresses all look right in the map file.  However, the programs always load at (external) flash 0x14000000 even when I request it to load at some other address (such as 0x14080000).  In LPCXpresso, you determine the load address by identifying the first flash memory block in the MCU settings page.  However, that does not appear to work with MCUXpresso.

Is there a new load address setting somewhere in MCUXpresso that I'm not aware of?  I can't seem to find such an option.

Thanks!

0 Kudos
Reply
3 Replies

1,444 Views
ritesh_singh
Contributor I

Hi,
samething I'm also facing the issue with MCUXpresso ide while working on LPC54S018 flashless controller

I'm able to set memory addresses in MCU setting and also it is reflecting in linker file as well as in map file

but when i'm debugging with jlink segger debugger connected on SWD pins on baord.
it always shows programming at BANK0  @0x10000000

I'm not able to test any program at anyother adddress except 0x10000000.

what to do ???

0 Kudos
Reply

1,880 Views
edarrington
Contributor II

I may have misled you on the problem.  In fact, I'm not sure I can point you to the problem at all yet.  For some reason, when using MCUXpresso with the generic flash driver to load code into flash (and verified that the correct code is there), as soon as I take the SPIFI into command mode, then back into memory mode in my application, all the code in flash gets somehow initialized.  All of flash.  I'm not sure why, and I didn't even think that was possible.

However, in my attempts to figure it out, I did find what I think is a bug in clock_18xx_43xx.c in function Chip_Clock_SetDivider().

This line:  

   /* Mask off bits that need to changes */
   reg &= ~((0x1F << 24) | 1 | (0x0F << 2));

does a nice job of masking off the divider values for IDIV_A-D, but does not clear all the bits for IDIV_E.  If the IDIV_E is set to something that uses the top four bits (anything over 15), then those bits remain set even if you set the divisor to a smaller number.

The line should read

   reg &= ~((0x1F << 24) | 1 | (0xFF << 2));

Thanks.  I will let you know if I figure out what else is going on with the flash.

0 Kudos
Reply

1,880 Views
lpcxpresso_supp
NXP Employee
NXP Employee

I wouldn't expect to see any differences generally in this respect between LPCXpresso and MCUXpresso IDEs.

Can you provide your map file along with the debug log, both for LPCXpresso IDE and MCUXpresso IDE?

https://community.nxp.com/message/630852 

Also please confirm the debug probe being used, the MCU being targeted, and the host OS.

Regards,

MCUXpresso IDE Support

0 Kudos
Reply