I've been trying to program the STM32L432 Nucleo-32 board using the mbed compiler. It has not been working. I can program a range of other boards without any problem. I noticed that the programming LED did not change when I tried to program the device and remembered that I had seen this before. The problem seems to be as follows: When you load a program on to an MBED enabled Nucleo-32 board the firmware in the loader checks to see if the first 32 bit word (which will form the initial stack pointer) lies within the available RAM on the target. The value output by the mbed compiler for the L432KC is 0x20010000 - the top of the 64kB or RAM. This should be ok you would think however it is rejected by the loader. Using a hex editor I changed the first word to 0x20008000 (the top of a 32 kB block of RAM) and it worked. So, either there is a bug with the mbed linker script and/or initialization files or the loader on the Nucleo board is mis-interpreting the available RAM.

Hi Frank -

It sounds like a bug in the ST-Link firmware that decodes the start of file. Have you updated ST-Link firmware? Here is a link. http://www.st.com/en/evaluation-tools/nucleo-l432kc.html

Let me know if this helps and if not I can try to get a board or ask someone at ST to give this a try.

Hi Sam, I upgraded the firmware (ST-Link firwmare on the nucleo board) to the latest version (V2J29M18). It still does not work with the initial stack pointer output by the mbed compiler. If I hexedit the bin file I can set the initial stack pointer to 0x2000C000 - the top of SRAM1. It seems mbed wants to put the stack pointer into SRAM2. SRAM2 is parity checked RAM. Is this available/suitable for use as a stack immediately following boot?

I'd expect it to but the MCU support in ST-Link must expect it at 0x2000C000. Does it fail to program if you set the SP to 0x2000C004?

From the datasheet:

3.5 Embedded SRAM
STM32L432xx devices feature 64 Kbyte of embedded SRAM. This SRAM is split into two
blocks:
• 48 Kbyte mapped at address 0x2000 0000 (SRAM1)
• 16 Kbyte located at address 0x1000 0000 with hardware parity check (SRAM2).
This memory is also mapped at address 0x2000 C000, offering a contiguous address
space with the SRAM1 (16 Kbyte aliased by bit band)
This block is accessed through the ICode/DCode buses for maximum performance.
These 16 Kbyte SRAM can also be retained in Standby mode.
The SRAM2 can be write-protected with 1 Kbyte granularity.
The memory can be accessed in read/write at CPU clock speed with 0 wait states.

Hi Sam, it fails at 0x2000C004 also. I wonder does the ST-Link probe the RAM to see if it is writable or is it hardcoded? Maybe it reads SRAM size from a config register in the MCU which is returning only the size of SRAM1? Either way, it would seem that the value output by mbed is not usable with the nucleo l432kc boards. Can it be changed to 0x2000C000?

Let's get someone from ST to comment on the best way to proceed but I'd guess its hard coded in ST-Link firmware.

Hello,

Please double check the ST-Link firmware is really V2J29M18. An issue was fixed in this version, available since 22 september on http://www.st.com/en/development-tools/stsw-link007.html. I just checked the link given by Sam previously and it is OK. I updated the ST-Link firmware with the pointed executable and was able to program afterwards an application with Stack pointer = 0x2001 0000.

Then investigate if something else with the application or the microcontroller itself might make it not run with stack pointer on SRAM2. I mean for instance the SRAM2 option bytes (parity check enable, erase on system reset). The option bytes may be verified with ST-LinkUtility: http://www.st.com/content/st_com/en/products/development-tools/software-development-tools/stm32-software-development-tools/stm32-programmers/stsw-link004.html

Sam, Sylvain, I'm embarrassed to admit that there were 2 nucleo boards plugged in to my computer when I did the firmware upgrade. As luck would have it, the one that got the update was the one around the back I'd forgotten about. Anyway, I put the new V2J29M18 firmware on the correct board and it now accepts images from the mbed compiler. Thanks again for your help. Frank.

Nothing to be embarrassed about, glad its working for you now.