The same coremark source code runs normally in ra mcu, but the following CRC-related error is displayed in n2l. What is the reason? I just changed coremark's clock source from systick to gpt because coretex-R doesn't have systick
github.com/.../coremark
start coremain!!! [16:09:06.088]收←◆2K performance run parameters for coremark. [0]ERROR! list crc 0x7271 - should be 0xe714 [0]ERROR! matrix crc 0x7fc1 - should be 0x1fd7 [0]ERROR! state crc 0x44f1 - should be 0x8e3a CoreMark Size : 666 Total ticks : 30024 Total time (secs): 30.024000 Iterations/Sec : 666.133760 Iterations : 20000 Compiler version : GCC10.3.1 20210824 (release) Compiler flags : Please put compiler flags here (e.g. -o3) Memory location : STACK seedcrc : 0xe9f5 [0]crclist : 0x7271 [0]crcmatrix : 0x7fc1 [0]crcstate : 0x44f1 [0]crcfinal : 0xf1c1 Errors detected FSP_PRIV_CLOCK_ICLK=200000000 running!!!
This is caused by the lack of stack.
1、I found that there are many kinds of stacks in rzn2l. Is there any documentation to explain the difference between these six types? Which stack is used for stacking ordinary functions and local variables?
2、I also checked the map file but it didn't seem to help. In addition, I also tried to modify the ld file, using atcm and sram mirror for all or part of the segment, coremark difference is very large, at least 300, at most 1300, but not up to 1700
.bss : { . = ALIGN(4); __bss_start__ = .; _bss = .; *(.bss*) *(COMMON) . = ALIGN(4); __bss_end__ = .; _ebss = .; _end = .; } > SYSTEM_RAM_MIRROR .heap (NOLOAD) : { . = ALIGN(8); __HeapBase = .; /* Place the STD heap here. */ KEEP(*(.heap)) __HeapLimit = .; } > SYSTEM_RAM_MIRROR .thread_stack (NOLOAD): { . = ALIGN(8); __ThreadStackBase = .; /* Place the Thread stacks here. */ KEEP(*(.stack*)) __ThreadStackLimit = .; } > SYSTEM_RAM_MIRROR .sys_stack (NOLOAD) : { . = ALIGN(8); __SysStackBase = .; /* Place the sys_stack here. */ KEEP(*(.sys_stack)) __SysStackLimit = .; } > SYSTEM_RAM_MIRROR .svc_stack (NOLOAD) : { . = ALIGN(8); __SvcStackBase = .; /* Place the svc_stack here. */ KEEP(*(.svc_stack)) __SvcStackLimit = .; } > SYSTEM_RAM_MIRROR .irq_stack (NOLOAD) : { . = ALIGN(8); __IrqStackBase = .; /* Place the irq_stack here. */ KEEP(*(.irq_stack)) __IrqStackLimit = .; } > SYSTEM_RAM_MIRROR .fiq_stack (NOLOAD) : { . = ALIGN(8); __FiqStackBase = .; /* Place the fiq_stack here. */ KEEP(*(.fiq_stack)) __FiqStackLimit = .; } > SYSTEM_RAM_MIRROR .und_stack (NOLOAD) : { . = ALIGN(8); __UndStackBase = .; /* Place the und_stack here. */ KEEP(*(.und_stack)) __UndStackLimit = .; } > SYSTEM_RAM_MIRROR .abt_stack (NOLOAD) : { . = ALIGN(8); __AbtStackBase = .; /* Place the abt_stack here. */ KEEP(*(.abt_stack)) __AbtStackLimit = .; } > SYSTEM_RAM_MIRROR
Hello Jerry
Google gave me an explanation of stacks here:https://stackoverflow.com/questions/13300427/not-understanding-arm-hardware-stacks-using-iar
IRQ_STACK
CSTACK
SVC_STACK
FIQ_STACK
UND_STACK
ABT_STACK
So, you have to increase the size of SYS stack size.
BR, Manuel
fsp_ram_execution.zipThe coremark result has a great relationship with the.text.data section. Please help to add the.text.data section of atcm on the basis of changing the ld file
Hello Jerry,
I think it is not a good idea to modify the linker script without being able to test it (whether it can be linked, if the sections are large enough, ...)
Currently .text and .data are linked to SYSTEM_RAM_MIRROR:
.text 0x30000000 : AT (0x30000000){ ...} > SYSTEM_RAM_MIRROR
.data :{ ...} > SYSTEM_RAM_MIRROR
You can try to use ATCM/BTMC instead.
On the Renesas website you should be able to find other sample applications that run from ATCM/BTMC only.
Hi Manuel
I still need the help of Renesas, because the primary sram is very practical and important, and the secondary atcm is necessary in my opinion, because the execution speed of coremark in sram and atcm is very different, and the memory of atcm is not big enough. I tried several ways to modify the ld file and copy atcm at boot time (r01an6737xx0100-rzn2l-separating-loader-and-application; r01an6789xx0101-rzn2l-bacnet), but all have various problems.
.... .flash_contents 0x6000004C : AT (0x6000004C) { _mloader_text = .; . = . + (_loader_text_end - _loader_text_start); _mloader_data = .; . = . + (_loader_data_end - _loader_data_start); _mfvector = .; . = . + (_fvector_end - _fvector_start); _matcm_text = .; . = . + (_atcm_text_end - _atcm_text_start); _matcm_data = .; . = . + (_atcm_data_end - _atcm_data_start); _mtext = .; . = . + (_text_end - _text_start); _mdata = .; . = . + (_data_end - _data_start); flash_contents_end = .; } > xSPI0_CS0_SPACE ...... .atcm_text : AT (_matcm_text) { _atcm_text_start = .; */src/coremark/*.o(.text*) _atcm_text_end = .; } > ATCM .atcm_data : AT (_matcm_data) { _atcm_data_start = .; __atcm_data_start = .; */src/coremark/*.o(.data*) __atcm_data_end = .; __atcm_bss_start = .; */src/coremark/*.o(.bss*) */src/coremark/*.o(COMMON) __atcm_bss_end = . ; _atcm_data_end = .; } > ATCM ..... void atcm_user_init(void) { /* Copy the atcm_user data from external Flash to internal RAM. */ bsp_atcm_user_data_init(); /* Clear atcm_user bss section in internal RAM. */ bsp_atcm_user_bss_init(); //test uint32_t data_num; for(data_num = 0; data_num < SRAM_DATA_NUM; data_num++) { temp_sram_data[data_num] = sram_data[data_num]; } }
The above code is modified by referring to r01an6737xx0100-rzn2l-separating-loader-and-application. The compilation is passed, but the relevant code cannot run when debugging. My analysis is logical, but I don't know what the problem is. And help analyze, also attach the project zip filerzn2l_coremark.zip
I am sorry, probably I won't be able to check this in detail this week.
Generally, the approach of separating-loader-and-application is good.For the loaded application you just have to replace or modify the linker script and the startup.c. I would recommend to take those of the sample as they are and adapt them slightly step by step.
Please note that the linker scripts can no longer be generated by FSP. If overwritten by FSP they must be manually replaced again.The startup.c is executed twice, once by the loader, once by the application. Some parts like memory protection initialization must be taken out from the one or the other, otherwise the system will crash.
separating-loader-and-application 0100 has been removed from the official website and can no longer be downloaded, and upgraded to 0110, their app practices are very different. I just referenced the 0100 practice, but in 0110 it's completely different. And I learned that the main purpose of the separating-loader-and-application project is still to let developers understand the startup process, and it is still possible to use the wizard to create a new xspi boot on the actual product. In addition, separating-loader-and-application uses two projects, and the loader project merely copies the ram and has no other role, which is inconvenient for the actual product development.
To sum up, I still think that when the wizard creates a single xspi boot project, sram is the first choice and atcm is the second choice. This is the optimal solution, and I have made progress in half a month, only the last step is left.
I would like to ask if other site administrators have time this week and could they help debug the project?
Thank you very much. I will review it again and the problem has been preliminarily solved.Forgot to copy text
But there are still two small problems:
1, coremark 800+, higher than 300+, lower than 1300+, what else can be improved?
2, debug project can not directly click resume, you must first click restart and then resume. I know that this is related to the fast switching between arm and thumb modes, I have made 3 attempts, adding latency in startup, adding latency in halentry, adding rzn2l_xspi0_x1_boot.cfg file, but nothing seems to work
The purpose of separating-loader-and-application project is to show a flexible approach to load one (maybe out of several) applications from a boot loader with as few modifications to the app as possible.
Of course also with the normal approach it is possible to load further code and data to other memories, but this is maybe more complicated.
The 110 version has the big advantage that memory addresses and sizes are automatically calculated by the linker, which avoids faults but accidentally wrong or forgotten adaptations.
Please note that this is a linker/arm/gnu/... topic, and actually not Renesas specific.
Hi jerry,Did you resolve your issue completely? Is there anything else to assist you? Would you like to verify the suggested answer if it was resolved? Kind Regards.
I still want to ask why the rzn2l coremark results are so low.
Regardless of the total score (400M), the maximum will not exceed 2000. It is also the result of CoreMark/MHz, only 3-4CoreMark/MHz. rzn2l (R52) compared with M7 core 500M, coremark total score can reach 3000, CoreMark/MHz can reach 5-6CoreMark/MHz
Even using certified data, rzt1 600M TCM 1900, this result is not as high as the M7 kernel
In this regard, you may contact the Renesas Technical Support team or open a related support ticket on the RZN2L website (Contact Technical Support).