nucleo-l432kc about stm32freertos

[fpistm]

Hi @rayozzie,
I've tested one MCU per STM32 series. As I've tested the Disco L475, I didn't test the L432KC.
Anyway, port should be generic and ok for the L432KC. I will test it and report my result.
Maybe a STM32FreeRTOSConfig.h to add to change some behaviour.

[rayozzie]

Thank you. Strange that it just hangs immediately inside the first call (to create a task), but havent been in a position to debug yet. Thanks again

[fpistm]

Hi @rayozzie
I've made some test.
In fact, there was a regression on the core. The Serial was not well initialized after a change I've made.
This is corrected thanks this commit:
stm32duino/Arduino_Core_STM32@c322ae5

I've tested those examples without any issue:

• AnalogRead_DigitalRead
• Blink_AnalogRead
• frBlink
• frBlinkPrint
• frJitter
• frLiuLayland

Let me know if it is ok.

[rayozzie]

Thanks. Appreciated. I'd already worked around this, but...that doesn't seem to be the issue.

The issue is that the very first (and any) calls to pvPortMalloc within the task will fail.

I can send you a debug project if you like, but it's easy to repro: just put a pvPortMalloc(1) at the top of either/both of your threads, and it will fail.

Oddly, the malloc's done within freertos on the path to creating the task seem to work fine. But by the time the task executes, something is wrong.

Please let me know if you'd like a debug project; thx.

[fpistm]

At a first step, could you post one sketch showing the issue, please?

[rayozzie]

I'm on my way into a meeting, and i apologize because i could probably make it much simpler, but here is a sketch into which i ported the smallest bit of code from my own project.

https://www.dropbox.com/sh/c8nbklouxks0aou/AAB6BolXnlAujYemlY8cK6ZAa?dl=0

In essence, the only parts that i duplicated are:

1. my serial initialization and debugf() method that does a printf to the serial port
2. my code which hooks traceMALLOC so that i could see the entire history of mallocs
3. a pvPortMalloc(1) and pvPortMalloc(2) at the tops of threads 1 and 2, and a dump showing when the results have failed.

What you will see on the serial output is:

begin
[following is the dump from thread1, as indicated by the fact that the last alloc attempt was (1)]
00001 malloc(80): 0x20000de0
00002 malloc(512): 0x20000e38
00003 malloc(92): 0x20001040
00004 malloc(512): 0x200010a0
00005 malloc(92): 0x200012a8
00006 malloc(512): 0x20001310
00007 malloc(92): 0x20001518
00008 malloc(200): 0x20001578
00009 malloc(1024): 0x20001648
00010 malloc(92): 0x20001a50
00011 malloc(1): 0x00000000
[following is the dump from thread1, as indicated by the fact that the last alloc attempt was (2)]
00001 malloc(80): 0x20000de0
00002 malloc(512): 0x20000e38
00003 malloc(92): 0x20001040
00004 malloc(512): 0x200010a0
00005 malloc(92): 0x200012a8
00006 malloc(512): 0x20001310
00007 malloc(92): 0x20001518
00008 malloc(200): 0x20001578
00009 malloc(1024): 0x20001648
00010 malloc(92): 0x20001a50
00011 malloc(1): 0x00000000
00012 malloc(2): 0x00000000

[fpistm]

Ok I've clean your sketch to properly used Serial. :)

To be more precise, your board does not hang. only the pvMalloc is failed. This is my case, malloc failed then led blinked properly.

It seems it is linked to the nano libc.
Removing --specs=nano.specs in platform.txt allow to perform allocation.

I found this article about using newlib nano and freertos.
http://www.nadler.com/embedded/newlibAndFreeRTOS.html

[rayozzie]

I’ll check that nano note out. Thanks. (Not sure if there is a structured/supportable way of modifying platform.txt, and I hope that if a fix is necessary that it ends up in the stm32duino repo.) It is interesting, though, that the mallocs done by freertos itself seemed to work, ... and then stopped working. If u can re-share the sketch back, it would be appreciated. I was indeed having some challenges at the beginning getting both UARTS working, and what you saw was where I’d ended up. Email is ray at ozzie dot net Thx

[fpistm]

In your sketch the Serial you declared was not used. How you would use them ?

[rayozzie]

I need two serial ports in my sketch, which is a port from another module. As I declared them in that sketch, they both work fine, on those specific pins of course. I’m out of my element with the library, but I do hope you folks can figure this out. In my app I’m trying to make available some source code, with relatively simple instructions to download stm32duino & stm32dunio freertos, to make it work. Your workaround does indeed unblock me for the moment, but it’s not viable to require users to edit platform.txt. Thanks for your help and understanding.

[rayozzie]

Frederic, I have now largely completed the port of my sketch to the NUCLEO-L432KC, and it works fine - but only if I use your workaround of removing --specs=nano.specs in platform.txt.

My app doesn't use a single malloc or pvPortMalloc, however I do use mutexes and tasks, and the very first xSemaphoreCreateMutex() fails. Empirically there is some incompatibility or regression that impacts stm32duino when using the nano memory allocator.

In the context of my solution, I can't have developers mucking around in the platform.txt because this is more-or-less a task that is far more sophisticated than they're up to. Can you please advise how to get this into the queue of issues to be addressed by the stm32duino devs?

Thanks again for your assistance. I'd not have gotten to this point at all without your help.

[fpistm]

Ray, thanks for the feedback.
Currently, I will not have enough bandwidth to investigate this.
I've a huge workload to do before my vacations en of august.
I will get back to this after.
Anyway, any other contributors could help on this topic.

[rayozzie]

Thanks, Frederick. This is not a short term blocker and it was not my intent to imply urgency. I'm not familiar with the processes here, and just wanted to make sure that by not communicating I didn't allow things to permanently fall through the cracks. Have a great holiday.

[rayozzie]

Frederic,

I know that you won’t be working on this until after holiday, and by the time you get back I may be traveling. As such, I wanted to give you all the info that I have about the bug(s) here. There are actually three interesting data points.

L476RG:
The problem requiring the workaround (removing --specs=nano.specs from the platform.txt) also manifests itself on the NUCLEO-L476RG board, not just the NUCLEO-L432KC board. This was much easier for me to debug because it has much more memory.

PRE MALLOC/FREE:
When I started using the L476RG after having removed the —specs=nano.specs, I knew that there should be quite a bit of memory available in my sketch. However, even with the above workaround, the memory available via malloc() (which is equiv to pvPortMalloc for heap_3.c) was pitifully low.

I decided to get back to basics, and I started experimenting with your MemoryAllocationStatistics.ino. This was quite interesting, and I stumbled across an odd behavior completely by accident.

In that sketch, you have a section that allocates, then frees, all of memory. I turned a variant of that into a simple method that just prints the amount of free memory, and put it back into my code.

Amazingly, if I put a call to that method as the very first thing in my Arduino setup() method, immediately I have more than 80KB available to my sketch, and it works perfectly. However, if I remove that call, there is less than 6KB available to my sketch. It’s incredibly odd: by alloc’ing and free’ing all of memory right up there at the top of setup(), it impacts the amount of memory available to FreeRTOS.

I know this sounds strange, but I did verify it extensively and so I’m confident that what I’m saying is true.

NEWLIB NANO corruption
Once I found that issue, I decided to use the L476RG go back to platform.txt and to restore the —specs=nano.specs, and to try it. I left my “calculate free memory” method call in the code, and tried it again.

What I found was even more troubling: The loop of malloc() successfully did grab around 80kb indicating that even with the newlib it was seeing that amount of memory free. However, within that method, in the loop that does free() calls to return the memory back to the runtime, it crashes within the third iteration of the loop, within free().

Remember that this is when this method is called right up at the top of setup(), and nothing else is happening in the system. And so it looks as though the allocator itself is causing the corruption, perhaps on the coalesce operation.

I hope this helps, whenever you get to it.

Ray

[rayozzie]

I know that you are not actively working on this until Sept, but I just wanted to tell you three observations from additional work yesterday:

1. regardless of the workaround that you had suggested, malloc() is not working reliably at all regardless of whether using newlib or not.
2. when looking on the web for other info yesterday, I found that there were numerous people who had run into this and had reduced it to something related to _sbrk being coded incorrectly. I don't know what the issue was, but rather than wasting time on newlib etc you may just focus directly on that.

[fpistm]

@rayozzie
I will check _sbkr implementation.

Could you share you tests sketch with the method that just prints the amount of free memory,
Thanks