2 - Memory functions implementation and wrapping

[sergiotomasello]

Solved the issue found while testing PR #10

[godario]

The problem with the never enumerated SerialUSB came from the uxCriticalNesting variable declared with initial value 0xaaaaaaaa instead of 0x0.

Using wrapping from the linker and using the malloc/calloc/realloc functions of FreeRTOS, an access to a critical section is performed at each allocation and, therefore, interrupts are disabled.

The purpose of the uxCriticalNesting variable has been well explained by Richard and, as he said:

When a critical section is entered, interrupts are disable and uxCriticalNesting is incremented. When a critical section is exited uxCriticalNesting is decremented, and if then it is zero the nesting has unwound and interrupts enabled.

In our case, since uxCriticalNesting is initialized by vTaskStartScheduler() and not before, calling a malloc BEFORE vTaskStartScheduler(), the interrupts are disabled but no longer re-enabled and this is because FreeRTOS think that it still in the critical section, and in fact the SerialUSB could not complete the handler negotiation (which uses an interrupt). The solution, as mentioned at the beginning, was simply to declare uxCriticalNestingwith an initial value of 0.

[sergiotomasello]

Hi @BriscoeTech any news? did you tested that PR? Regards

[BriscoeTech]

Hello again @sergiotomasello and @godario

Great work finding the problem. Thanks for posting that link, that was a very interesting read and not something I would have thought about going into it.

I merged your changes to its own development branch, and tested it with the basic examples, as well as one of my massive rtos projects and everything seems to be working great :-). I plan on merging this to the master branch soon.

After playing with the linker settings in platforms.txt, it would be great to make the linker setting associated with a board variants instead of all the core boards. I can see people getting frustrated when they decide to go back to a non rtos project and the linker fails because they forgot they made the linker change back. It would be great to make a new board variant and label it as being FreeRtos, and people can jump between the default and FreeRtos board variants :-)

I did some poking around and it is supposedly possible based off of this link: https://github.com/arduino/Arduino/wiki/Arduino-IDE-1.5-3rd-party-Hardware-specification

platform.local.txt

Introduced in Arduino IDE 1.5.7. This file can be used to override properties defined in platform.txt or define new properties without modifying platform.txt.

I haven't tried this yet, and its getting late so I will play with this later this week. If that works we can update the readme and people can make their own board variants. Depending on how platform.local.txt works, I may also include a template file for people to grab and use.

Great work, thanks again!

[sergiotomasello]

Hi @BriscoeTech we are glad to help and happy to hear everything works well. We hope to see this feature branch merged soon ☺️ Do you perhaps planned integrations and tests on platform.local.txt and board variant?

Regards

[BriscoeTech]

Hello @sergiotomasello and @godario

So I spend some time playing with the platform.local.txt and it works slightly different than I interpreted from the website. The platform.local.txt is a convenient alternative to modifying the platform.txt, if you place platform.local.txt in the same directory as the platform.txt, its settings will override the platform.txt. I tried moving platform.local.txt to be in a board variant folder with no luck, and had to do alot of searching to realize this was not their intent.

Good news is I think this will still work out well. I made a folder in the repos root directory called "wrapping memory functions" and created a copy of my platform.local.txt file for people to use. What people can do is copy and paste this file into their board folder to enable this feature, and either delete or rename the file to disable the feature to be able to build non rtos projects again. I wrote a detailed setup guide inside the platform.local.txt file, and outlined what has to be done in the Arduino Ide or Slober (I use both) to make it work.

I also spent last weekend deploying the managed memory version to 10 of my systems and everything seems to be running very well.

I have only run into one non-repeatable problem: I have a i2c oled splash screen that gets initialized before the rtos is started, and I am noticing corruption on the screen when the device boots up. What is interesting is it is random and not repeatable, and it is a new problem since using the managed memmory code, but I also decided to render the splash screen before the rtos has started about the same time so it may be a coincidence ;-) I am not too worried as it only happens at startup and have had no problems once the rtos is running. The image rendered is a 1024 byte static const unsigned char array. I have some ideas on how to diagnose this, but I dont think it warrens delaying the release, its probably something I have done.

I have merged these changes and they are now apart of master branch v1.0.0.

Thanks again for the changes, I will let you know if I find anything else interesting with the memmory management :-)