nucleo-l432kc

[rayozzie]

After wondering why it linked and loaded onto the board, but then crashed on the first freertos call, I just realized that the nucleo-l432kc isn't in the table showing that it's a tested device.

Not understanding the constraints of the port - is the 432kc something that should work even if not tested, or is this a bridge too far?

thanks.

[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.