-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Failing flashiap tests on DISCO_L475VG_IOT01A #7867
Comments
ARM Internal Ref: MBOTRIAGE-1549 |
cc @ARMmbed/team-st-mcd |
Hello,
FYI my setup is the following
I have tried your command line
I have created a mbed_app.json containing
and it gives the same error as the one you described |
@adustm That's correct. My findings were along the similar lines as to adding just the flag to collect all the stats (-DMBED_ALL_STATS_ENABLED) causes the issue. I am still investigating as to why that is. My understanding is that that flag collects all memory information and might be doing some allocation/deallocation and may be much more, so at this point I am not completely sure if this is an issue with the target or something we are doing while collecting the stats. |
The issue here is memory. When all the stats are enabled, we dont have enough memory on this part to run this test. It fails to allocate 512 bytes. When trying to run flashiap_timing_test, we have to allocate bunch of memory, so we can add a change that would skip that test if we cannot get enough memory for it, something along the lines of this PR: #7696 Besides that, we would also need the change in this PR pulled in: #7730 |
Tested few other devices with tests-mbed_drivers-flashiap and those flags here is output:
looks like only targets stm32-47x have this issue |
Nucleo F070 does not have an issue (much smaller target) but L476 does? Is there also playing role memory regions (1 vs 2 RAM regions or something else) ? |
Hi @MateuszMaz Hi @0xc0170
Let's keep searching |
To be a little more precise problem occurs for flag -DMBED_HEAP_STATS_ENABLED=1 |
Hello, Those devices (STM32L476 / 475 / 486 ) have 2 non contigous SRAMs. Crash analysis document explains that
The provided dump Kind regards |
hello again, Crash log parser says:
This mean that the error occurs here in mbed_alloc_wrappers.cpp
We've been able to find 2 ways of fixing the problem (no explanation so far...)
=> test is ok
=> test is ok Both modifications fixes the test. Please note that adding a printf in main.cpp / flashiap_init_test function makes the program fail during flashiap_init function instead of flashiap_timing_test function On the other hand, we 've checked heap settings
There is 84k of heap... should be sufficient... I hope this will help you finding the issue. |
I found that this problem is not related neither to greentea nor FlashIAP, and thanks to @maciejbocianski help I also know that it occurs only for GCC_ARM. It is indeed related to memory allocation. Just make a simple program, and compile it with -DMBED_HEAP_STATS_ENABLED=1 -t GCC_ARM
this one will result in something similar:
|
HI all
|
Hi @LMESTM this was done in an abundance of caution. The default implementation only returns 8 byte aligned data and some things, such as stacks require 8 byte aligned memory. To ensure there were no regressions the 8 byte alignment was kept. |
Thanks for quick feedback @c1728p9. In our particular case, removing the padding, therefore removing this extra caution step and keeping structure with 4 bytes only, somehow solves our issue ... |
It appears that this failures is caused by a mismatch between the allocation size newlib expects and the size actually allocated. Depending on the size of the first allocation (if it is a multiple of 32 bytes) then the alignment done in mbed-os/targets/TARGET_STM/TARGET_STM32L4/l4_retarget.c Lines 50 to 64 in 00b7700
I took the DISCO_L475VG_IOT01A board and was able to reproduce the crash when heap stats was turned on. I recorded the values inside of Successful run without heap stats enabled:
Crash when heap stats is turned on:
If I modify |
I created #7950 to fix this. Please test and confirm it fixes the problem. |
@c1728p9 based on recent observations, we were heading in a similar direction and planned to remove the alignment but we can not explain why the alignment was causing the failure. you suggestion is :
so ok we'll consider sbrk needs to allocate exactly what is requested and no more. Fine with me. |
Description
Bug
Target
DISCO_L475VG_IOT01A
Toolchain:
GCC_ARM
Tests we are failing:
tests-mbed_drivers-flashiap
Steps to reproduce
mbed test -m DISCO_L475VG_IOT01A -t GCC_ARM -n tests-mbed_drivers-flashiap -DMBED_HEAP_STATS_ENABLED=1 -DMBED_STACK_STATS_ENABLED=1 -DMBED_TRAP_ERRORS_ENABLED=1 -DMBED_ALL_STATS_ENABLED -v
log snippet
The text was updated successfully, but these errors were encountered: