[Question] About linker.ld for heap location (for some third-party lib)

[Visit-Learn]

Hi,

Currently, we are doing porting lib into MT3620 FreeRTOS SDK, but some of our lib need to know the heap location, so we need to add .end into likner.ld. And due to we are not familiar with MT3620, so do you have suggestion for this case about how to arrange it? Because if we do not declare it into linker.ld, the compiler will output below error: sbrk.c:(.text._sbrk+0x18): undefined reference to `end'

We think that we only can put .end into SYSRAM scope, is it correct? But this looks like the FreeRTOS use full memory of it, we may need your comment about this (if having a example is much better for us).

Thank you so much.

[kevinwh-chou]

Hi,

That's what we did as well, putting end = .; after the user data section (ex. .data, .bss) to denote the start of the heap, as this is expected by _sbrk, otherwise that error pops up.

I'm not sure what's the concern with respect to "end" in your comment "But this looks like the FreeRTOS use full memory of it", in our case, the FreeRTOS heap locates in SYSRAM, and it's the only thing using SYSRAM (the data / code region are in TCM).

Let me know if I misunderstand anything.

[Visit-Learn]

Hi,

Currently, we try to move code into flash and we use MT3620_RTApp_FreeRTOS_UART example for testing, and we found that when device run to mtk_os_hal_uart_dma_send_data, the device is freezed (cannot output message from UART anymore) . Could we know any limitation or incorrect setting to lead this situation? Thank you so much

Modified linker.ld REGION_ALIAS("CODE_REGION", FLASH); REGION_ALIAS("RODATA_REGION", FLASH);

Thanks a lot.

[kevinwh-chou]

Hi,

Yes, it seems using DMA function externally in the flash may cause some problems. We will look into it and update to you. For the moment please execute your code in the TCM.

[Visit-Learn]

Hi,

Thank you for your information.

By the way, currently we are porting third-party library into MT3620 and we have code size issue and I am not very familiar with build tool and compiler, so could I know how to modify compiler optimized level? Thanks.

And actually, our project is also using mailbox and SPI and when we move code into flash the device is also freezed, but I have not dive into the examples MT3620_RTApp_FreeRTOS_MBOX and MT3620_RTApp_FreeRTOS_SPIM have same issues or not. Just to let you know, thanks.

Thank you so much.

[kevinwh-chou]

Hi,

Thanks for sharing the info, got it. I don't know how much space you will need, and which part dominates (by analyzing the map file XXX.map, in out/ARM-Release or ARM-Debug)?

Setting to release mode instead of debug mode when building the code will further reduce size, as it's more optimized. Check the following lines in AzureSphereRTCoreToolchainMTK.cmake.

set(COMPILE_DEBUG_FLAGS $<$<CONFIG:Debug>:-g2> $<$<CONFIG:Debug>:-gdwarf-2> $<$<CONFIG:Debug>:-O0>)
set(COMPILE_RELEASE_FLAGS $<$<CONFIG:Release>:-g1> $<$<CONFIG:Release>:-O3>)
add_compile_options(-Wall ${COMPILE_DEBUG_FLAGS} ${COMPILE_RELEASE_FLAGS})

[Visit-Learn]

Hi,

Yes, we check code size from map file and we know that ARM-Release can reduce about 20 KB from ARM-Debug. And thank you information for optimized level.

By the way, our third-party lib may need space for 80 KB - 100 KB, so that why we need to move code into flash, thanks a lot.

Thank you so much.

[Visit-Learn]

Hi,

We think that below two examples have same issue, when RT code moves from TCM to FLASH; the RT core (M4) is freezed. Thanks a lot.

MT3620_RTApp_FreeRTOS_MBOX MT3620_RTApp_FreeRTOS_SPIM

[kevinwh-chou]

Hi,

Thanks for sharing. Any functions that may use IRQ and run in the flash will end up in the same failed case. We just figured out the cause and verifying the solution, once it's done, the solution will be updated to the Github, hopefully in the following few days.

[Visit-Learn]

Hi,

Thanks for sharing. Any functions that may use IRQ and run in the flash will end up in the same failed case. We just figured out the cause and verifying the solution, once it's done, the solution will be updated to the Github, hopefully in the following few days.

Hi,

Thank you so much, got it.

[LawranceLiu]

The solution is included in the release_200911

[Visit-Learn]

Hi,

Got it, thank you so much, we will add those modification into our project then testing. We will close this case before 2020/09/24 if there has no further questions, thanks a lot.

Thanks.