LPC1776 loading incorrect value from internal RAM

[lpcware]

Content originally posted in LPCWare by Alex on Thu Aug 28 01:41:52 MST 2014
Hi,

I wrote a program, which is going to be started by a bootloader also written by me.

When the program is started by the bootloader it sets the stack pointer back to the start of stack. But unfortunately the stack pointer loaded from addrs 0 is incorrect. As you can see on the screenshot the stack pointer should be 0x100010E8 but the value that is received from RAM is 0x10001FFC. This lead to a hard fault later in the program.

The screen shot shows the startup code (program entry point), the memory at address 0, the disassembly and the current CPU registers after executing MSR.

Any ideas what is going wrong there?

Best regards
Alex

[lpcware]

Content originally posted in LPCWare by Alex on Wed Sep 03 02:15:20 MST 2014
Hi mc,

the issue exists as long as a debugger session is connected during reset.
I implemented a workaround by setting the stack pointer using
ldr r0,=SFE(CSTACK)
msr msp,r0

As this is the only point where the memory remapping has an influence on the software there is no problem for me any longer.
Thank you.

kind regards
Alex

[lpcware]

Content originally posted in LPCWare by mc on Tue Sep 02 15:02:45 MST 2014
Hi Alex,
By default device will execute boot ROM when it comes up from reset. Has your problem been resolved?

[lpcware]

Content originally posted in LPCWare by Alex on Tue Sep 02 03:00:18 MST 2014
You are right, it is the memory remapping that caused this trouble.

The values read after reset are values from Boot ROM.

Thank you for the support.

[lpcware]

Content originally posted in LPCWare by Alex on Tue Sep 02 01:38:47 MST 2014
You are right, it is some kind of debugger issue...

When I run the program without connecting a debugger session, the read data is correct, when I connect the debugger it is some other data...

I will verify if it has something to do with memory remapping that is possibly interrupted by the debugger. And afterwards I will contact NXP.

[lpcware]

Content originally posted in LPCWare by Pacman on Mon Sep 01 10:15:24 MST 2014
I wonder if this is a debugger-issue.

What happens if you read the values, store them for later, set up UART and transmit the values via UART to a console ?

[lpcware]

Content originally posted in LPCWare by DF9DQ on Mon Sep 01 09:06:36 MST 2014
MEMMAP is documented in chapter 38 of the user manual. It determines whether the CPU sees the user flash or the boot ROM content when it reads from address 0 (I think the first 512 bytes or so are remapped).

[lpcware]

Content originally posted in LPCWare by Alex on Mon Sep 01 05:45:53 MST 2014
Interesting thing:
When I stop execution on the first instruction and do single stepping the data loaded from flash is correct...

Maybe it is a timing issue?
Does the FLASH need some time to become ready after power on? Pipeline issue?

[lpcware]

Content originally posted in LPCWare by Alex on Mon Sep 01 05:44:23 MST 2014
Hi Pacman,

obviously it is another memory region that is read. I attached a screenshot showing the registers and so on...

[lpcware]

Content originally posted in LPCWare by Alex on Mon Sep 01 05:37:41 MST 2014
Hi DF9DQ,

what do you mean with memmap register? Is it the VTOR register?

Currently I believe that I don't use any memory remapping after power on reset. The debugger should display the content of FLASH address 0.

[lpcware]

Content originally posted in LPCWare by DF9DQ on Sun Aug 31 23:44:30 MST 2014
Maybe you can verify that the MEMMAP register is not 0. The stack pointer value that gets loaded (...1FFC) could be the one used in the boot ROM.

I don't use IAR myself, but what the debugger presents to you as the current content of address 0 may actually be a cached version.from the time when MEMMAP was 1...

[lpcware]

Content originally posted in LPCWare by Pacman on Fri Aug 29 04:08:43 MST 2014
Sorry; I was confused, because I usually don't use debuggers (well, never used debuggers for microcontrollers).
Hmm.. Indeed, this looks strange.
Just to make sure you're loading data from the right place in memory, try this...

ldm r0,{r0-r7}

... instead of the ldr r0,[r0]. Then compare the memory contents to address 0x00000004 ... 0x0000001c and see if they match.

[lpcware]

Content originally posted in LPCWare by Alex on Thu Aug 28 23:48:47 MST 2014
Hi Pacman,

you are right, I don't read the value from RAM but from internal FLASH ROM. Sorry, my fault.

But the problem still remains.
The first instructions after program entry at __iar_program_start are to set r0 to zero than loading r0 with the memory content addressed by r0 and then set the stack pointer using msr msp,r0. You can also see what has been executed in the disassembly tab. The instruction marked green has not been exectued yet.

The problem is that the value received from address zero is not the same as the value stored in FLASH ROM. Please take a look at the memory tab and the registers tab in the screenshot.

According to the ARM Cortex M3 specification address 0 is the memory location where the stack pointer will be taken from after power on reset. It is also the first entry of the exception table. the reset vector is stored at address 4 and so on.

[lpcware]

Content originally posted in LPCWare by Pacman on Thu Aug 28 13:28:14 MST 2014
Uhm... It looks like you're loading r0 with the value #0, not the contents of address 0x00000000.

Eg.
    ldr r0,=0   /* zero register r0 */
    ldr r0,0     /* read the contents of address 0 into r0 */

You may need to do this, though:
    movs r0,#0  /* zero r0 */
    ldr     r0,[r0]  /* read the initial stack pointer address */

Another thing...
As you're using the LPC1776, which has 64kB on-chip main SRAM, you have the address range 0x10000000 to 0x1000ffff.
Normally, you would place the stack at the end of SRAM, which would be 0x10010000 (no, you can't read from that address, but as the address is pre-decremented, the first word that is stored, is stored in address 0x1000fffc, not 0x10010000).
If you want to support all devices with at least 16kB SRAM, the stack address could be 0x10004000.