Yes I know 🙂
Sorry, sometimes it’s difficult to estimate what knowledge is present already.
0x00025800 0x00020000 Zero RW 451 HEAP startupCMSDKCM3.o
0x00045800 0x00002000 Zero RW 450 STACK startupCMSDKCM3.o
The size of the heap – stack section is 128 KB. The heap starts at an offset of 150 KB.
On the other hand, according to the debugger the start addresses of tasks
stack are: 0x00010DE8, 0x00011728, 0x00011B50, 0x000123C8. I don’t
understand why they are not located in the STACK memory region.
The stack at 0x45800 will only be used
at start-up. Once
vTaskStartScheduler()
has been called, each task will have its own stack, allocated by heap_4.c
0x0001178c 0x00013880 Zero RW 1106 .bss heap_4.o
You reserved 80,000 bytes of HEAP.
I suppose that “HEAP startup
CMSDKCM3″ is the system heap, which is unused? If it is unused, you might want to increase your actual heap in
heap_4.c
.
Are you using
pvPortMalloc()
and
vPortFree()
in all cases, and not
malloc()
and
free()
?
What MCU are you using? Are the above memory addresses all located in valid RAM?
~~~~
lr = 0x0000031F
pc = 0x41000000
psr = 0xA5A5A5A5
~~~~
It looks like
lr
points to a RAM location. But it may also be rubbish.
And
pc = 0x41000000
, isn’t that a reset address?
Are you using BufferAllocation
1.c or BufferAllocation2.c?
In case you use BufferAllocation
1.c, what does your vNetworkInterfaceAllocateRAMToBuffers()
look like?
Note that BufferAllocation1.c contains some useful debugging code, in case you define
ipconfigTCP_IP_SANITY = 1
.
If you want you can email all relevant source code to me and I will check it.
It will be something simple like calling
vReleaseNetworkBufferAndDescriptor()
once too often, or writing to memory that has been released already.