”_user_heap_stack“ _ user_ heap_ What does this mean

[pzh11001]

Great work

I want to free up as much memory as possible for storing data. ”_ user_ heap_ Stack "occupies 140KB of memory。So I moved "_user_heap_stack" to the 288KB memory block of D2. Can be compiled and passed normally。But grblhal stopped working。 why？

[pzh11001]

[dresco]

Hi, appears that the call to malloc() is failing in nvs_buffer_alloc(), resulting in an error later when trying to load settings data.

After a bit of digging, I think you also need to change this line in the linker file to actually move the stack & heap into RAM_D2;

/* Highest address of the user mode stack */
_estack = ORIGIN(RAM_D1) + LENGTH(RAM_D1);    /* end of RAM */

However, it will then hard fault at startup unless you make some changes to the early init code, see here for details..

Seems to be running okay for me after doing that, however there will be some other implications. Just off the top of my head - the SDMMC1 peripheral has no DMA access to RAM_D2, but should fall back to using a scratch buffer in .bss (though will be slower).

Just out of interest, what board are you testing on (and what config needs the extra RAM)?

[pzh11001]

I use the STM32H750VBT6 development board of WeAct, although the manual indicates that the H750VBT6 has only 128K FLASH. But in fact, I can still write GRBLHAL into the microcontroller correctly through DFU mode. There seems to be no difference between H750 and H743!

I need to use GRBLHAL to control my 6axis RobotArm. The kinematics algorithm is completed on the upper computer, converted into G code and sent to GrblHal. Because of the kinematics algorithm of the RobotArm if the RobotARM's TOOL needs to move a straight line or a track, I have to send G code every very small track distance (such as 0.1mm) to ensure the smoothness of the track. When 0.1mm in the Cartesian workspace of the RobotArm is converted to the drive joint of the RobotArm and finally converted to the motor, the motor movement angle may be less than 0.05 degrees.

In order to make the end of the RobotArm move quickly along the track correctly, I need a lot of G codes. The distance of each G code movement is very short. I also need these G codes to execute quickly after motion planning. In order for the planner to plan a certain speed, the total amount of these G codes needs to be very large to add up to a certain length.

So I need a huge BLOCK_ BUFFER_ SIZE, such as 3000+.

I know that the upper computer cannot send G code at such a fast speed, so I store the G code in the SD card in advance for execution

[pzh11001]

After GRBLHAL did not work, I recovered the code.

Then I reduced them:

_ Min_ Heap_ Size = 0x200 ; /* 0x20000 required amount of heap #####KKKKK */

_ Min_ Stack_ Size = 0x400 ; /* 0x3000 required amount of stack * #####KKKKK/

Then GRBLHAL works well! What is the role of the "_user_heap_stack" stack space? Why does it need to be 140 KB in size, and why does GRBLHAL still work normally after shrinking?

By the way, I need the SD card function of GRBLHAL

[dresco]

I need to use GRBLHAL to control my 6axis RobotArm.

Cool!

I use the STM32H750VBT6 development board of WeAct, although the manual indicates that the H750VBT6 has only 128K FLASH. But in fact, I can still write GRBLHAL into the microcontroller correctly through DFU mode. There seems to be no difference between H750 and H743!

Yes, there have been a couple of people confirm the H743 code works fine on the H750 (including saving settings into the last 128KB of the 2MB flash that shouldn't exist!). Has been said that H750 may just be H743 parts that failed flash validation, but who really knows..

What is the role of the "_user_heap_stack" stack space?

I think it's purpose is just to make the linker throw an error if there is not at least that much free space left (normally after .data & .bss).

Why does it need to be 140 KB in size, and why does GRBLHAL still work normally after shrinking?

The values probably came from the upstream F7 driver (or perhaps from ST sample code), but how much is really needed will depend on what plugins etc are in use. Am sure they can be safely reduced somewhat, I can successfully build with a BLOCK_ BUFFER_ SIZE of 3000 if I drop the min heap size to 0x10000

@terjeio recently added some upstream code to help track heap usage, which is also in the H7 driver. I believe this was meant to be exposed through WebUI, but it could also be displayed in a plugin for tracking your actual usage?

[pzh11001]

Thank you very much for your answers. After these operations, your GRBLHAL can run normally. When 8-axis, BLOCK_ BUFFER_ SIZE=4000 ！！

It is very fast, very accurate, and really a perfect transplant.

I will continue to learn the development of STM32H7 single-chip microcomputer, and hope to successfully run the robotarm based on GRBLHAL controller in the future.

Thanks again!

[terjeio]

The reason for increasing the heap size is that I have added a new setting for allocating the block buffer from the heap at run time, this is currently optional but will become default later. See the build 20220918 entry in the changelog.
I may add a $-command for outputting heap usage later, currently only drivers supporting the WebUI has the needed HAL entry set, wider driver support for it has to be added first?

[pzh11001]

The reason for increasing the heap size is that I have added a new setting for allocating the block buffer from the heap at run time, this is currently optional but will become default later. See the build 20220918 entry in the changelog. I may add a $-command for outputting heap usage later, currently only drivers supporting the WebUI has the needed HAL entry set, wider driver support for it has to be added first?

I think this change is very meaningful. You can automatically allocate cache space according to the current remaining memory size. It can improve performance and give consideration to stability. And users can expand the driver at will without considering the memory usage.

Looking forward to the new version