Wrapping app_main() causes test to fail

[PeterR]

I am debugging an issue which seems to be related to the start up stack's size.

Example https://github.com/lllucius/esp32_extfl ... a10be629a2 works.
If however I modify the test harness (see attached file), where I have simply renamed original app_main() as app_main_ext() and then call from a new app_main()

Code: Select all

app_main(void *)  // New, just calls old renamed
{
	app_main_ext();  // Call renamed original function
}

Then this does not work.
I have increased CONFIG_MAIN_TASK_STACK_SIZE and CONFIG_TIMER_TASK_STACK_SIZE

Also - is there anything special which I need to know about app_main()
Perhaps the test is writing wild & pushing auto variables deeper reveals the issue?

[PeterR]

uxTaskGetStackHighWaterMark(NULL) reports watermark of 3880 (I set 5684). I can see that I have increase the startup task's size.

Calling the original (renamed) app_main() from new app_main() fails with above watermark.
Placing ExtFlash at file scope allows the program to work again though.

So the watermark cannot be the whole story but seems auto related.

[fly135]

Change the declaration...

ExtFlash flash;

to be outside the function and at global or file scope (or alloc dynamically). Not sure how big ExtFlash is, but best not to put objects on the stack unless you know how big there are and have a handle on stack usage.

John A

[PeterR]

Thanks.
ExtFlash is quite small (check the link). The stack's watermark shows that I have plenty of space left. Fails even if I allocate 16K to main.
The program does 'work' if I place ExtFlash at file scope.

However the problem also shows in my application where I dynamically create ExtFlash & hold within a thin wrapper.
It looks then more as if something is hitting ExtFlash?

The only thing common between my application & ExtFlash demo is ExtFlash & ESP32 (including SPI driver).
ExtFlash uses half duplex & DMA which I have not used on ESP32 yet.
I am aware that 'Half duplex transactions with both read and write phases are not supported when using DMA' but I think the driver uses command and address instead?

So there seems to be a collision which clearly I do not understand. AFAIK only ExtFlash, FreeRTOS and SPI interrupts are running and so I need to find the cause.

[PeterR]

ExtFlash constructor is incomplete. 'is_qpi' was not initialised. Most of the time it initialised false.
For my use not.
I guess that adding the extra calls allowed me to find a previously used part of memory.
The dangers of downloading code...
I wish I had JTAG pins free & could use a debugger.

Thanks for taking an interest.

[fly135]

OK, let's go back to square one. First, why are you focused on the stack size? Second, telling us your app failed is virtually useless information. I only responded to your claim that stack was the issue, but now I'm seeing that you have no idea what the problem is.

You need to go back and capture the log file and post it here since you have no information other than it works until I add another function call.

John A

[PeterR]

I did 'seem' to think that the issue was stack size.
I was wrong, the problem was/is the uninitialized member in the ExtFlash project.
Close but no prize.
The log would not help. The error causes the application to freeze (which would have been easy to see if I had pins free for a debugger).
I did consider adding more detail but thought that without a SPI flash it would be pointless & so was relying on those who had used ExtFlash.

The fix is simple.
If I could figure how to close this then I would.