LPC1756 secondary boot loader fails when jumping into application

[lpcware]

Content originally posted in LPCWare by robertpalmerjr on Wed Jan 14 09:07:35 MST 2015
I am using the AN11258 I2C secondary boot loader as the reference for my development.

I have successfully implemented the core boot loader, my problem occurs when I jump to the application.  The application is built using the RedLib library.  I have traced the problem to the following extent:

- boot loader jumps into app's entry point (ResetISR in cr_startup_lpc176x.c)
- ResetISR calls __main
- __main (inside redlib doing some kind of "magic" that I can't see or modify) calls _initio
- _initio calls _Csys_alloc requesting 192 bytes
- _Csys_alloc calls malloc requesting 192 bytes
--- FAIL --- malloc returns 0
- Csys_alloc calls __sys_write then __sys_appexit (infinite loop)

I have read every thread on this forum that I can find related to boot loaders.  Before I call my application, I reset the SP and set the VTOR to point to my application's vector table.  The application's ResetISR routine run's successfully until the memory allocation request.  It's not "crashing" - i.e. not a memory bus exception dropping into one of the exception vector routines.

The application works fine if I compile it with a base address of 0x00 instead of 0x1000

Is there a bug in RedLib????

I do not want to switch libraries (though I guess I could for testing purposes) because one module of my code has been through certification and changing the stdC library for the app will mean I have to change the stdC lib for the module as well, which would require recertification. 

Here is the memory table for my boot loader:
FLASH  loc: 0x00  size 0x1000
RAM  loc: 0x10000000 size 0x3c00
RAM2 loc 0x10003c00 size 0x400
RAM3 loc 0x2007c000 size 0x4000

and for my application:
FLASH  loc: 0x1000  size 0x1f800
FLASH2 loc: 0x3fffc size 0x4
RAM  loc: 0x10000000 size 0x3c00
RAM2 loc 0x10003c00 size 0x400
RAM3 loc 0x2007c000 size 0x4000

Any assistance in figuring out why this isn't working would be greatly appreciated

[lpcware]

Content originally posted in LPCWare by robertpalmerjr on Wed Jan 14 11:58:02 MST 2015
RESOLVED

Always pay attention to the obvious!

Heap check was failing because I was out of heap space.  I had modified the memory allocation to set aside a permanent buffer for the boot loader.  This reduced my heap size by 1k, which was enough to cause the app to not have enough memory to function.  A change in the location of this buffer and I'm off and running.  Sorry for the distraction.

[lpcware]

Content originally posted in LPCWare by robertpalmerjr on Wed Jan 14 10:47:08 MST 2015
Ok, I obviously can't send my main project, but I will try to pare it down to something very short that I can post.

I am using LPCXpresso 5.4.2, again, because of the certification issue.   Can you provide any info on the bug.   What I'm seeing is that malloc appears to add 3 to the requested byte count and then divide by 4, I assume to get number of 32bit words.  It then does, what appears to be a loop check, which fails.  When the loop check fails, it adds 12 to the originally requested amount (192 + 12 = 204 bytes) and calls _sbrk which then calls __check_heap_overflow which fails.  Check heap first compares the stack pointer to the current top of heap, then to the top of heap AFTER adding the requested allocation.  This is where the failure is happening.  The first compare is successful, the second is not.

It seems that the heap or stack is not allocated correctly or is being tested incorrectly.

I found an issue about this in the forums, but that seemed to be related only to freeRTOS

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Wed Jan 14 09:38:10 MST 2015
There was a rare bug in malloc() in Redlib prior to v7.5.0 - perhaps you are falling over that? But without an example that shows the problem, we can't tell you for certain.