Hi David,
So sorry for my later reply.
I get some information from our internal expert side, but I still don't have time to test it.
Please follow this suggestion, and test it on your side at first.
---------------------------------------------------------------------------------
So the basic question is - why does a system work under debug but fail on Power On Reset. The answer turns out to be a stack access performed by the ResetISR function before the flexRAM reconfigure is performed. See the disassembly of the ResetISR function...
00000000 <ResetISR>:
0: b510 push {r4, lr} // this stack access causes a fault
2: b672 cpsid i
4: 4b1a ldr r3, [pc, #104] ; (70 <ResetISR+0x70>)
6: 6b9a ldr r2, [r3, #56] ; 0x38
8: f442 0210 orr.w r2, r2, #9437184 ; 0x900000
c: 639a str r2, [r3, #56] ; 0x38
e: 4a19 ldr r2, [pc, #100] ; (74 <ResetISR+0x74>)
10: 645a str r2, [r3, #68] ; 0x44
12: 6c1a ldr r2, [r3, #64] ; 0x40
14: f042 0207 orr.w r2, r2, #7
18: 641a str r2, [r3, #64] ; 0x40
1a: 2300 movs r3, #0
1c: e000 b.n 20 <ResetISR+0x20>
1e: 4613 mov r3, r2
The very first instruction (at the entry point of the application) is a push to the stack - and at this point, put the memory in place for the first stack access.
There are a number of potential fixes to this problem.
1 - you could re-write the resetISR function in assembler
2 - you could set the fuses with the FlexRAM settings
3 - or you could leave the project memory configuration for the Stack to be in available memory (for the very first push) and then make a change to the new value. This first push is not necessary since we will never return from this function.
So - if the project memory is left like this:
You can then simply poke a new SP value. I tested this with the code as below:
My test code fragment:
__attribute__ ((section(".after_vectors.reset")))
void ResetISR(void) {
// Disable interrupts
__asm volatile ("cpsid i");
IOMUXC_GPR->GPR14 |= (9 << 20);
IOMUXC_GPR->GPR17 = 0x55FFAAAA;
IOMUXC_GPR->GPR16 |= 7;
__asm volatile ("mov r12, #0x20000000"); // here I reset the stack to the value I wanted at 0x20040000
__asm volatile ("orr r12, #0x40000");
__asm volatile ("mov sp, r12");
This asm code puts the Stack at 0x2004000 after the FlexRAM memory has been set correctly.
This is a bit 'nasty' and I think we need to investigate a better solution to this problem. I will raise a Jira to investigate the issue of ResetISR pushing data to the stack.
Please confirm that this 'fix' also works in your environment.
------------------------------------------------------------------------------------
Please help to check it, whether it works.
When I have time, I will also test it.
Any test result from yourside, please kindly let me know.
BTW, please note, when you divide the ITCM DTCM size, you need to meet the following demand:
The Arm Cortex-M7 specifications require the size of ITCM/DTCM to be a power-of-two number, which can conflict with the FlexRAM configuration capability (see configurations 7, 10, 11 in Table 1).
AN12077.
Have a great day,
Kerry
-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------
I was able to change the project to locate stack at the beginning of the DTCM memory section instead of the default at the end.
This allows the stack to be used by ResetISR in a valid memory range before the FlexRAM is reconfigured.
