Get memory map values (from MCU Settings) in application code

lpcware · ‎06-15-2016

Content originally posted in LPCWare by ArriaLive on Tue Aug 04 18:51:11 MST 2015
I've been looking for a way to reference the MCU Settings table in code, but have not yet been successful. Is there a way?

In our application, running on an LPC4330, we have defined multiple regions of the external flash something like this (from code_Debug_mem.ld file):

/* Define each memory region */
RamLoc128 (rwx) : ORIGIN = 0x10000000, LENGTH = 0x20000 /* 128K bytes */
RamLoc72 (rwx) : ORIGIN = 0x10080000, LENGTH = 0x12000 /* 72K bytes */
RamAHB32 (rwx) : ORIGIN = 0x20000000, LENGTH = 0x8000 /* 32K bytes */
RamAHB16 (rwx) : ORIGIN = 0x20008000, LENGTH = 0x4000 /* 16K bytes */
RamAHB_ETB16 (rwx) : ORIGIN = 0x2000c000, LENGTH = 0x4000 /* 16K bytes */
CodeFlash (rx) : ORIGIN = 0x14000000, LENGTH = 0x20000 /* 128K bytes */
[color=#900]Region1Flash [/color](rx) : ORIGIN = 0x14030000, LENGTH = 0x40000 /* 256K bytes */
[color=#900]Region2Flash [/color](rx) : ORIGIN = 0x14020000, LENGTH = 0x10000 /* 64K bytes */
[color=#900]Region3Flash[/color] (rx) : ORIGIN = 0x14070000, LENGTH = 0x40000 /* 256K bytes */

I have read that there may be a way to create an external reference such as:

extern int Region1Flash;

and then let the linker resolve the value. However, I have not been able to get the linker to resolve any reference I can think of. Is there a simple way to accomplish what we're trying to do?

Thanks!

lpcware · ‎06-15-2016

Content originally posted in LPCWare by lpcxpresso-support on Fri Aug 21 14:57:19 MST 2015
The SYSRESETREQ signal behavior (LPCxpresso default) is vendor dependent. The idea behind this signal was to allow a way to reset other IP blocks in addition to the core. The actual behavior varies between part families, even within the same vendor. The LPC18xx and LPC43xx part families behave reliably using VECTRESET. You might have noticed the boot reset scripts for these parts actually force the reset signal to VECTRESET.

Thanks and regards,
LPCXpresso Support

lpcware · ‎06-15-2016

Content originally posted in LPCWare by ArriaLive on Thu Aug 20 13:59:35 MST 2015

Quote: lpcxpresso-support
Here's something to try with regard to the Vector catch option. In your project Debug Configuration "Debug" tab you'll see a "Reset Handling" option. Set this to "VECTRESET" (core reset only) when you use the Vector catch option set to 'true'. Let us know how you get on.

This recommendation so far has worked very well! In fact, VECTRESET doesn't seem to get in the way whether Vector Catch is TRUE or FALSE, but when TRUE, it (so far) works every time!

For you information, I have gathered the debug messages for a couple examples. Perhaps this will help someone along the way:

With Vector Catch: TRUE and Reset Handling: [blank] (This happens every time, and requires a power cycle of the target device):

Quote:
LPCXpresso RedlinkMulti Driver v7.9 (Jul 23 2015 14:19:54 - crt_emu_cm_redlink build 468)
Found chip XML file in C:/Users/Ed/Documents/git/Arria-Firmware79/Arria_boot/Debug/LPC4330.xml
Probe Firmware: LPC-LINK2 CMSIS-DAP V5.112 (NXP Semiconductors)
VID:PID: 1FC9:0090
USB Path: \\?\hid#vid_1fc9&pid_0090&mi_00#8&3a15eb26&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
Vector catch on SYSRESETREQ signal
Emu(0): Connected&Reset. DpID: 4BA00477. CpuID: 410FC240. Info: <None>
Debug protocol: JTAG. RTCK: Disabled. Vector catch: Enabled.
loaded v.2 External Flash Device on SPI C:\nxp\LPCXpresso_7.9.0_455\lpcxpresso\bin\Flash\LPC18_43_SPIFI_GENERIC.cfx
image 'LPC18/43 Generic SPIFI Jul 15 2015 11:50:47'
AFTER driver startup timeout
Driver Register State
R0:     10089000
R1:     00000000
R2:     00000000
R3:     00000000
R4:     00000000
R5:     00000000
R6:     00000000
R7:     00000000
R8:     00000000
R9:     00000000
R10:    00000000
R11:    00000000
R12:    00000000
SP:     10080FE0
LR:     FFFFFFF9 (exception from main thread)
PC:     FFFFFFFE
xPSR:   01000003
MSP:    10080FE0
PSP:    10081000
CFBP:   00000001
Exception information:
10080FFC: xPSR:   01000000
10080FF8: VECTPC: 10000034
10080FF4: LR:     10000035
10080FF0: R12:    00000000
10080FEC: R3:     00000000
10080FE8: R2:     00000000
10080FE4: R1:     00000000
10080FE0: R0:     10089000
E000ED04: ICSR:   00400803 (ISRPEND, VECTPEND=0, RETTOBASE, VECTACTIVE=3)
E000ED38: BFAR:   E000EDF8
E000ED28: CFSR:   00000001
E000ED2C: HFSR:   00000002 (VECTBL)
E000ED30: DFSR:   00000000
E000ED3C: AFSR:   00000000
E000ED24: SHCSR: 00000000
Flash Driver V.2 startup failed - rc Ef(34): Timed-out initializing flash.
Connected: was_reset=true. was_stopped=false
LPCXpresso Free License - Download limit is 256K
============= SCRIPT: LPC18LPC43ExternalFLASHBootResetscript.scp =============
Boot from FLASH image pc/sp reset script
PC = 0x00000000
SP = 0x00000000
XPSR = 0x00000012
VTOR = 0x00000012
RedlinkAPI: Wire Ack Fault - target connected?
============= END SCRIPT =====================================================
Target error from Set break/watch: Ep(20). Unable to set an execution break - no resource available.
(crt_emu_cm_redlink) terminating due to request from GDB

With Vector Catch: TRUE and Reset Handling: VECTRESET:

Quote:
LPCXpresso RedlinkMulti Driver v7.9 (Jul 23 2015 14:19:54 - crt_emu_cm_redlink build 468)
Found chip XML file in C:/Users/Ed/Documents/git/Arria-Firmware79/Arria_boot/Debug/LPC4330.xml
Probe Firmware: LPC-LINK2 CMSIS-DAP V5.112 (NXP Semiconductors)
VID:PID: 1FC9:0090
USB Path: \\?\hid#vid_1fc9&pid_0090&mi_00#8&3a15eb26&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
Vector catch on VECTRESET signal
Emu(0): Connected&Reset. DpID: 4BA00477. CpuID: 410FC240. Info: <None>
Debug protocol: JTAG. RTCK: Disabled. Vector catch: Enabled.
loaded v.2 External Flash Device on SPI C:\nxp\LPCXpresso_7.9.0_455\lpcxpresso\bin\Flash\LPC18_43_SPIFI_GENERIC.cfx
image 'LPC18/43 Generic SPIFI Jul 15 2015 11:50:47'
flash variant 'S25FL256S 64kSec' detected (32MB = 512*64K at 0x14000000)
Connected: was_reset=true. was_stopped=false
LPCXpresso Free License - Download limit is 256K
Writing 67776 bytes to address 0x14000000 in Flash
Progress meter completed at over 100% (81920/67776 bytes)
Erased/Wrote page 0-1 with 67776 bytes in 4086msec
Flash Write Done
Flash Program Summary: 67776 bytes in 4.09 seconds (16.20 KB/sec)
============= SCRIPT: LPC18LPC43ExternalFLASHBootResetscript.scp =============
Boot from FLASH image pc/sp reset script
PC = 0x14000A05
SP = 0x10020000
XPSR = 0x01000000
VTOR = 0x00000000
============= END SCRIPT =====================================================

Stopped: Breakpoint #1

Thank you. It looks like we might have a solution!

lpcware · ‎06-15-2016

Content originally posted in LPCWare by lpcxpresso-support on Wed Aug 19 07:56:06 MST 2015

Here's something to try with regard to the Vector catch option. In your project Debug Configuration "Debug" tab you'll see a "Reset Handling" option. Set this to "VECTRESET" (core reset only) when you use the Vector catch option set to 'true'. Let us know how you get on.

Thanks and regards,
LPCXpresso Support

lpcware · ‎06-15-2016

Content originally posted in LPCWare by lpcxpresso-support on Wed Aug 19 04:11:04 MST 2015
Sorry: Inlining is an optimisation, which you can hint to the compiler that you want it to do. But -O0 means no optimisation, so you won't get any inlining regardless of any hints you have decorated your source code with.

If you want inlining to occur, then you need to either switch from -O0 to using a higher optimisation level, or use the explicit option to turn on inlining. The GCC docs break these inlining specific options down in quite some detail.

With regards to vector catch, there have been slight tweaks in the behaviour of this option made between 7.4.0 and 7.9.0 - but this has not been done arbitarily. It has been done fix specific issues that other users have reported. I am sorry that this is causing you problems. We will look to see if we can spot any obvious issue that might be triggering your problems though.

And finally with regards to access to ISP - we would always recommend that you allow access to this on development/test boards to allow debug recovery, regardless of flash etc in your system. This is the only guaranteed way of putting a part into a completely "clean" state.

Regards,
LPCXpresso Support

lpcware · ‎06-15-2016

Content originally posted in LPCWare by ArriaLive on Tue Aug 18 18:33:05 MST 2015
LPCXpresso Support,

Quote:
-O0 = No optimisation. Inlining is an optimisation. For more details check the GCC docs include in the product or online

I checked. It says: "Without any optimization option, the compiler's goal is to reduce the cost of compilation and to make debugging produce the [color=#900]expected [/color]results." Wouldn't an inline statement make inline code "expected"?

Same thing further down: "-O0 - Reduce compilation time and make debugging produce the [color=#900]expected[/color] results. This is the default." I stand by my position.

Quote:
Vector catch simply modifies the way that reset is handled by the debugger. Its exact behaviour can change between releases

A moving target sure makes development difficult for us developers.

Quote:
But generally the best way to recover a part is to use ISP. Not allowing for this on a development board (as opposed to a production one) is not a good idea - as you have found!

ISP doesn't buy us much because we are using a flashless part (LPC4330), and we can't reach flash memory using ISP (see table 33 in UM10503.pdf).

Until vector catch works when needed and doesn't cause initialization problems when not needed, our development team has returned to version 7.4. Too bad.

Thanks,

lpcware · ‎06-15-2016

Content originally posted in LPCWare by lpcxpresso-support on Fri Aug 14 05:10:01 MST 2015
-O0 = No optimisation. Inlining is an optimisation. For more details check the GCC docs include in the product or online at

https://gcc.gnu.org/onlinedocs/gcc-4.9.3/gcc/Optimize-Options.html#Optimize-Options

With regards to __RAMFUNC(), yes you can continue to use it. But just make sure you mark all the required functions with it!

Finally - Vector catch simply modifies the way that reset is handled by the debugger. Its exact behaviour can change between releases, as well as between different MCUs. It is also possible to change other aspects of the way reset is pulled by modifying the "Reset Handling" option in the launch configuration. But generally the best way to recover a part is to use ISP. Not allowing for this on a development board (as opposed to a production one) is not a good idea - as you have found!

Regards,
LPCXpresso Support

lpcware · ‎06-15-2016

Content originally posted in LPCWare by ArriaLive on Wed Aug 12 11:32:23 MST 2015

Quote:
I presume that you are testing a Debug build here? From what you are saying, it sound like your setup was working more by accident in LPCXpresso 7.4.0 than anything else. In LPCXpresso 7.4.0, the default optimisation level for Debug builds was -Og, but this was reverted back to -O0 as of LPCXpresso 7.5.0. This would explain why they are no longer being inlined.

The change from -Og to -O0 may be the culprit here. I changed all the projects in my workspace to -Og and everything compiled and ran just like the old days under 7.4.

However, I'm still troubled by that explanation. I understand the compiler looking at the code and optimizing to put some code inline where performance (or memory size) is being optimized. However, when an explicit compiler directive (such as "static inline") is included, the compiler should ALWAYS inline those functions--with any optimization level. Ignoring compiler directives is the opposite of optimization--it's unoptimizing (is that a word?). It is counter-intuitive. What's the point of the directive if it is removed by the optimization level of the compiler?

Still, if that's the issue, I'm happy to stick with -Og for now and move forward.

Quote:
I strongly recommend that you look at placing all the code from specific objects into RAM using the Freemarker linker script templates introduced in LPCXpresso 7.9.0, rather than the __RAMFUNC() macro.

I have to respectfully disagree. I've read the documentation on the Freemarker linker script (which I think is terrific, by the way--a great addition!), but in some cases it makes more sense to use the __RAMFUNC() macro. Even the documentation you reference says that when moving just certain functions, the best method is to use __RAMFUNC(). Moving that information to a linkscript somewhere creates visual separation between the function source and the RAM optimization. You have to look in two places to see what's actually going on. Seeing the __RAMFUNC() in front of the function gives you all the information in one place.

True, if I'm putting an entire file or library in RAM, the Freemarker script is a far easier way to do so, but in our case, we're trying to be very judicial about our use of RAM. In fact, we're putting these functions in RAM2, not RAM1 because we're trying to reserve RAM1 on the 4330 primarily for stack and heap, something our application uses extensively.

Quote:

Quote:
The most frustrating is that pressing the "step into" button when debugging in 7.9 actually operates exactly like the Resume button. It executes forward without stopping at the top of the highlighted function. This happens with ANY function I try to step into.

At what point do you see this? Is it whilst stepping into code that is in flash or in RAM? Does setting a breakpoint manually work?

I was seeing this problem consistently with every function regardless of whether it was in flash or in RAM. However, for some reason I cannot explain, after changing the optimization level to -Og, this problem has also gone away.

Quote:
This sounds like your code that is trying to access the SPIFI is leaving the device in a state that the flash driver cannot recover from (note that the flash drivers in 7.4.0 we based on a different SPIFI code base to 7.9.0). Does booting the board into ISP mode before starting the next debug session work?

Our target board (our own design) has pin P2_7 tied high specifically to eliminate the possibility of going into ISP mode, so that's not an option for us. But now that I'm able to actually debug some code, I have learned a little more about this issue.

Currently, if Vector Catch is turned on (which has been the normal mode for us under 7.4 to help us through the reset if clocks or memory are corrupted), I can get past any reset issues, but I get an error starting up:

Quote:

Error in final launch sequence
Failed to execute MI command:
-exec-continue
Error message from debugger back end:
Warning:\nCannot insert breakpoint 1.\nCannot access memory at address 0x14000948\n
Warning:\nCannot insert breakpoint 1.\nCannot access memory at address 0x14000948\n

This is tied to the "error reported by target":

Quote:
15: Target error from Set break/watch
Unable to set an execution break - no resource available.

This happens EVERY time vector catch is true. (Note, no breakpoints are set). When vector catch is false, I don't get the error, but I also can't get past the reset issue (should that come up) without using vector catch as true.

In 7.4, we just left vector catch on all the time to catch the reset error, but we didn't get the above errors. In 7.9, we apparently cannot leave vector catch as true.

The problem is, when we have a reset error, we must manually set vector catch to true, try to debug, get the error, power down the target, and back up again, then go change vector catch to false again, and re-debug. Those are very annoying and unnecessary extra steps in the process.

Vector Catch should not prevent the program from running. Is this vector-catch behavior unique to me as well?

Thank you again for sticking with me through this. We are, indeed, making great progress!

EdA

lpcware · ‎06-15-2016

Content originally posted in LPCWare by lpcxpresso-support on Wed Aug 12 04:02:23 MST 2015

Quote: ArriaLive

With respect to the 7.9 version of the IDE itself, I see some weird behavior. The most frustrating is that pressing the "step into" button when debugging in 7.9 actually operates exactly like the Resume button. It executes forward without stopping at the top of the highlighted function. This happens with ANY function I try to step into. This explains one of the reasons why I am having so much trouble debugging this problem--when I step into a function, it simply resumes execution. It is extremely difficult to debug this way. What could be making the step-into function not work correctly?

On this point, the FAQ:

https://www.lpcware.com/content/faq/lpcxpresso/placing-specific-functions-ram-blocks

highlights a debugging issue relating to the linkers possible use of long branch veneers where functions are physically a long way from each other within the memory map.

Due to the distance in the memory map between flash memory and RAM, you will typically require a "long branch veneer" between the function in RAM and the calling function in flash. The linker can automatically generate such a veneer for direct function calls, or you can effectively generate your own by using a call via a function pointer.

One point to note is that debugging code with a linker generated veneer can sometimes cause problems. This veneer will not have any source level debug information associated with it, so that if you try to step in to a call to your ram code, typically the debugger will step over it instead.

You can work around this by single stepping at the instruction level, setting a breakpoint in your RAM code, or by changing the function call from a direct one to a call via a function pointer.

I hope the above explains this particular issue.

Yours,
LPCXpresso-support

lpcware · ‎06-15-2016

Content originally posted in LPCWare by lpcxpresso-support on Wed Aug 12 01:23:41 MST 2015

Quote: ArriaLive

Looking at the MAP files from the 7.4 version and the 7.9 version (attached), the most obvious difference is that in the 7.9 version, the inline functions from the spifi library that are being used are not being compiled inline. They show up as independent functions (which happen to be in flash--the wrong place for them, of course, see lines 7734-7740):

spifi_HW_GetStat
spifi_HW_SetCmd
spifi_HW_GetData8
spifi_HW_WaitCMD

It turns out that these are the only four functions that are used from the spifi library, but they are declared static inline, yet in 7.9 they show up as separate functions, and under 7.4 they are compiled in, and therefore don't show up in the link map.

I presume that you are testing a Debug build here? From what you are saying, it sound like your setup was working more by accident in LPCXpresso 7.4.0 than anything else. In LPCXpresso 7.4.0, the default optimisation level for Debug builds was -Og, but this was reverted back to -O0 as of LPCXpresso 7.5.0. This would explain why they are no longer being inlined.

https://www.lpcware.com/content/faq/lpcxpresso/optimize-for-debug

I strongly recommend that you look at placing all the code from specific objects into RAM using the Freemarker linker script templates introduced in LPCXpresso 7.9.0, rather than the __RAMFUNC() macro.

https://www.lpcware.com/content/faq/lpcxpresso/relocating-code-flash-ram

This should hopefully ensure that you don't miss functions.

Quote:

With respect to the 7.9 version of the IDE itself, I see some weird behavior. The most frustrating is that pressing the "step into" button when debugging in 7.9 actually operates exactly like the Resume button. It executes forward without stopping at the top of the highlighted function. This happens with ANY function I try to step into. This explains one of the reasons why I am having so much trouble debugging this problem--when I step into a function, it simply resumes execution. It is extremely difficult to debug this way. What could be making the step-into function not work correctly?

At what point do you see this? Is it whilst stepping into code that is in flash or in RAM? Does setting a breakpoint manually work?

Quote:

Second, when I get this weird crash, I must power down and up my target device and load code again to start over. I am not able to see variables, function addresses, or any other data I'm used to seeing in 7.4. RAM memory appears corrupted. When trying to terminate and debug again, I get errors unless I've completely powered down the target and started over. That also is frustrating given that all this code worked fine under 7.4, including the debug cycle.

What errors exactly? Please post the debug log...

https://www.lpcware.com/content/faq/lpcxpresso/debug-log

This sounds like your code that is trying to access the SPIFI is leaving the device in a state that the flash driver cannot recover from (note that the flash drivers in 7.4.0 we based on a different SPIFI code base to 7.9.0). Does booting the board into ISP mode before starting the next debug session work?

https://www.lpcware.com/content/faq/lpcxpresso/regaining-debug-access

Regards,
LPCXpresso Support

lpcware · ‎06-15-2016

Content originally posted in LPCWare by ArriaLive on Tue Aug 11 19:22:20 MST 2015
LPCXpresso Support,

I appreciate your staying with me on this, but please remember that my code ran perfectly under version 7.4 of the IDE. That means I have all the right code is in RAM (or at least it was under 7.4). The only change is upgrading to 7.9, then the code simply doesn't run.

Looking at the MAP files from the 7.4 version and the 7.9 version (attached), the most obvious difference is that in the 7.9 version, the inline functions from the spifi library that are being used are not being compiled inline. They show up as independent functions (which happen to be in flash--the wrong place for them, of course, see lines 7734-7740):

spifi_HW_GetStat
spifi_HW_SetCmd
spifi_HW_GetData8
spifi_HW_WaitCMD

It turns out that these are the only four functions that are used from the spifi library, but they are declared static inline, yet in 7.9 they show up as separate functions, and under 7.4 they are compiled in, and therefore don't show up in the link map.

I've looked at many static inline functions declared in our code, and the ONLY thing I can find that makes these unique is that they A) are called from a RAM2 function AND B) they are declared in a separately compiled library/file. I can't seem to find any other places in our code where both of those conditions are true.

[color=#03c][UPDATED]: After realizing that my searches were incomplete, I can now verify that [u]every[/u] static inline function call (that is actually called) creates it's own function in flash rather than compiling inline, according to the link map.[/color]

Any ideas?

With respect to the 7.9 version of the IDE itself, I see some weird behavior. The most frustrating is that pressing the "step into" button when debugging in 7.9 actually operates exactly like the Resume button. It executes forward without stopping at the top of the highlighted function. This happens with ANY function I try to step into. This explains one of the reasons why I am having so much trouble debugging this problem--when I step into a function, it simply resumes execution. It is extremely difficult to debug this way. What could be making the step-into function not work correctly?

Second, when I get this weird crash, I must power down and up my target device and load code again to start over. I am not able to see variables, function addresses, or any other data I'm used to seeing in 7.4. RAM memory appears corrupted. When trying to terminate and debug again, I get errors unless I've completely powered down the target and started over. That also is frustrating given that all this code worked fine under 7.4, including the debug cycle.

I have tried uninstalling 7.9 and reinstalling, but the weirdness remains.

I have attached map files from both the 7.4 and the 7.9 versions. The code sources are identical. I have also included a copy of our hw_spifi.h file which is mostly a copy of the spifi library .h file. Take a look and let me know what you think.

Thanks,
EdA

lpcware · ‎06-15-2016

Content originally posted in LPCWare by lpcxpresso-support on Tue Aug 11 05:10:29 MST 2015
This sounds like you haven't copied all the code/rodata required for updating the SPIFI into RAM. Double check the placement of code/rodata related to SPIFI access (from your code and SPIF library) within the map file generated by the linker.

Note that there have been changes with the way that LPCXpresso 7.9.0 works with regards to linker scripts which might be causing this issue. For more details see:

[list]
[*]https://www.lpcware.com/content/faq/lpcxpresso/freemarker-linker-script-templates
[*]https://www.lpcware.com/content/faq/lpcxpresso/relocating-code-flash-ram
[/list]

If you need more help, I suggest at least posting your map file for us to look at. Or better still a buildable project that shows up the problem.

[list]
[*]https://www.lpcware.com/content/faq/lpcxpresso/how-importexport-projects
[/list]

Regards,
LPCXpresso Support

lpcware · ‎06-15-2016

Content originally posted in LPCWare by ArriaLive on Mon Aug 10 10:04:59 MST 2015
LPCXpresso Support,

Thank you for your response. Yes, I spent much of the weekend studying this issue and I have new information. The functions were, in fact, moving to RAM2, and actually seemed to run in RAM2. However, this was concealed by the fact that when stepping "into" a RAM2 function in the debugger, I would immediately get the hard fault. However, when going into the function itself and using run-to-line (or in the disassembler, run-to-instruction), I could see that the function was executing in RAM2--to a point.

But that did not solve the problem, of course. The functions that fail in RAM are those that are flash oriented. They run in flash because flash command-mode functions must be run in RAM. The interesting part is that as soon as we go into command mode in flash memory, the function *in RAM2* stops executing, the instructions (in the disassembler) are all 0xFFFFFFFF, and we get a hard fault. Why would changing the flash to command mode affect to code in RAM2?

For this case, I have to guess that the debugger is doing something weird, not the code itself. Still, the code does hard fault.

So, perhaps the issue is with flash memory. My guess is that whatever change was made to the IDE between 7.4 and 7.9 to speed up placing code in SPIFI memory has put the flash in a state that, when using my original flash driver, is causing some sort of incompatibility. To test this, we have started comparing our flash driver with the latest flash driver provided by LPC. Note that when we wrote the original flash driver, the Spansion flash memory we are using was not supported by the LPC library, so we copied what we could and finished the rest ourselves to maximize flash performance (clock rate, quad mode). That worked great with 7.4 of the IDE. As we try to resolve the issue with 7.9, one path we are considering is to use the latest flash library (which now supports our chip) and see if that makes a difference. Still, I'd sure like to know what is causing the problem. Is there a quick fix?

Any ideas what is causing the flash memory incompatibility problem?

Thanks,
EdA

lpcware · ‎06-15-2016

Content originally posted in LPCWare by lpcxpresso-support on Mon Aug 10 02:14:04 MST 2015
I am not aware of anything that would prevent this from working.

I have tried this functionality using the release 7.9 build on an LPC4370 project and (surprise) it works for me...

So fundamentally, does the call to your RAM function actually go the place you expect? If so, is the RAM function actually located in this place?

Take a look at the MCU setting (properties -> MCU settings) does your RAM2 region correspond the the location 0x10080000.
Take a look at the project.map file and check the symbolic information looks correct for your function and the RAM region.
Disassemble the RAMFUNC location and see if the expected code actually resides there.
If nothing seems incorrect, can you read and write this area of RAM from a memory editor (poke some 0x0 values into the RAM and set the PC to execute from that location, instruction level stepping should prove that RAM execution is working as it should).

I would expect one of these checks to shed light on the problem.

Yours,
LPCXpresso-support

lpcware · ‎06-15-2016

Content originally posted in LPCWare by ArriaLive on Fri Aug 07 10:31:04 MST 2015
LPCXpresso Support,

Thank you, I was successful programming the flash.

One more issue. My application code loads fine into flash and runs fine EXCEPT when I reach a function that I have moved into RAM using the __RAMFUNC(RAM2) (as stated in the document at https://www.lpcware.com/content/faq/lpcxpresso/relocating-code-flash-ram). This worked fine in 7.4, but results in a hard fault using 7.9. I've stepped through the code (even in disassembled mode) and as soon as it tries to make the call to that function, I get an immediate hard fault, so it must be related to the RAM2 shift.

I'm so close. What additional change have I missed?

Thanks!

lpcware · ‎06-15-2016

Content originally posted in LPCWare by lpcxpresso-support on Thu Aug 06 08:25:32 MST 2015
SPIFI flash driver changed considerably between 7.4 and 7.9 - they are much much faster, for example.

The new mechanism is described here:
https://www.lpcware.com/content/faq/lpcxpresso/lpc18-lpc43-spifi-flash-drivers
It should be a simple change for you.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by ArriaLive on Thu Aug 06 07:38:32 MST 2015
LPCXpresso-Support,

This solution is very helpful and appears to work well. I've been able to create the table (I even added size symbols), and I can compile. However, I do have one glitch.

We have been developing on version 7.4 of the IDE and have been sticking with that version for consistency. To add this feature, I installed version 7.9 of the IDE. I can compile all my projects, and link them, so that works, but I cannot debug in 7.9 because for some reason I can't get the flash to initialize and download the code. I get the EF(34) Timed-Out Initializing Flash error. I've searched the forums for information on this, I've tried a number of flash drivers (including the driver from the 7.4 version that was known to work), I've double-checked that 7.4 works (it does), and I've compared the debug settings in my 7.4 version with those of 7.9. The only difference appears to be the use of CMSIS-DAP instead of Redlink, but the docs say CMSIS-DAP is the new default.

What am I missing? How do I eliminate the EF(34) and get 7.9 to talk to the flash memory?

Thanks,
EdA

lpcware · ‎06-15-2016

Content originally posted in LPCWare by lpcxpresso-support on Wed Aug 05 03:20:24 MST 2015
By default, symbols are created for the top of each defined memory region - and you can see these within the proj_Debug_memory.ld (within the PROJECT debug folder) which is then automatically pulled into the auto created linker script for the project.

The simplest way to obtain the functionality you require to obtain the base memory region addresses within LPCXpresso 7.9.0 is to modify the managed linker script mechanism.

More information on managed linker scripts can be found at:

[list]
[*]https://www.lpcware.com/content/faq/lpcxpresso/freemarker-linker-script-templates
[/list]

At the top level of your project, create a folder called 'linkscripts' and drop the attached memory.ldt file into this folder. This will case a symbol for the base address of each defined memory region.

Once a rebuild is performed, you should see the new region symbols within the proj_Debug_memory.ld file.

To test this is working correctly within your code, you can access the values as below (here using the memory alias names for the first two Flash regions):

extern void *__base_Flash;
extern void *__base_Flash2;

printf("__base_Flash = %x\n",&__base_Flash);
printf("__base_Flash2 = %x\n",&__base_Flash2);

We will look to changing the defaults in the next release to automatically provide symbols for both the base and top each memory region.

Yours,
LPCXpresso-Support