fpistm / arduino_core_stm32l4

[Deprecated] STM32L4 support added to the Arduino_Core_STM32.

Hi there 👋

📈 GitHub Stats

arduino_core_stm32l4's Issues

Board seem to be running at 64Mhz not 80Mhz

PLL multiplier settings seem to be for the board to run at 64Mhz not the 80MHz as advertised on STM's website.

Looking in hw_config.c there are 2 possible speeds, controlled by a definition of ENABLE_HIGH_SPEED

However if the code is recompiled with ENABLE_HIGH_SPEED defined, the board seems to run even slower

PWM pins are not set in AF mode again

Work on NUCLEO_L476RG

How to reproduce the issue
start with D3 as PWM, works fine
change D3 as output
set back D3 as PWM, PWM doesn't work anymore.

Issues : GPIOB_3 isn't set as AF mode in 0x48000400 MODE15[1:0]= 01 instead of 10

you should add in analog.c ,line #708:
HAL_TIM_PWM_MspInit(&g_analog_config[id].timHandle);

after that it works fine

Winterrupts.c writes but never reads .configured

In various lines Winterrupts.c e.g.

https://github.com/stm32duino/Arduino_Core_STM32L4/blob/master/cores/arduino/WInterrupts.c#L43

.configured is written but never read.

These lines can be removed and

PinDescription g_intPinConfigured[MAX_DIGITAL_IOS];

can be changed to a array of pointers to PinDescription

(and the code changed accordingly)

Wire library not working?

Wire.endTransmission() always returns 4 (unknown error) on a stock NUCLEO-L476RG.

linker _user_heap definition may conflict with Arduino IDE RAM calculation

See http://stm32duino.com/viewtopic.php?f=48&t=1564&p=20198#p20198

@RickKimball posted

The way the arduino IDE calculates RAM usage and the way the linker script attempts to warn you about the low memory usage are in conflict. There are really 1536 bytes of RAM that the linker "allocates" to the heap and the stack. However, the linker's approach doesn't really reflect how much heap or RAM is used. The arduino IDE knows how much RAM a board/chip has and will report low memory issues with a warning about stability. However, neither approach is accurate.

You could probably change the linker script part here from:

 ._user_heap_stack :
   {
     . = ALIGN(4);
     PROVIDE ( end = . );
     PROVIDE ( _end = . );
     . = . + _Min_Heap_Size;
     . = . + _Min_Stack_Size;
     . = ALIGN(4);
   } >RAM

to:

 ._user_heap_stack :
  {
  . = ALIGN(4);
 PROVIDE ( end = . );
 PROVIDE ( _end = . );
 } >RAM

This would stop the reporting of a bogus RAM memory usage and in our case, the arduino IDE will start complaining if you are getting too close to the edge.

I2C pins are hard coded in the core

This is the same issue as in the F1 code.

I2C pins are hard coded in the core.
https://github.com/stm32duino/Arduino_Core_STM32L4/blob/master/system/libstm32l4/source/twi.c#L169-L180

Pins need to be different for each variant.

This has been discussed by @danieleff and myself, and we think easiest solution is to use #define for the pins, as it is difficult to change the twi code to move the whole init function to on of the files in the variant folder

Rework pinmap

This issue has been created to follow pinmap rework

Most of the g_analog_config does not need to be in RAM

Only the .dacInstance and .timInstance members of g_analog_config need to be in RAM

https://github.com/stm32duino/Arduino_Core_STM32L4/blob/master/system/libstm32l4/source/analog.c#L95

The rest of the struct is const. Hence these 2 members should be in their own separate arrays
g_analog_config should be declared as const
Code should be modified accordingly to match these changes

HAL callback functions in the core should should be declared as weak so they can be overridden in the sketch

HAL callback functions in the core should should be declared as weak so they can be overridden in the sketch

Compilation issues when including wire.h

When using MCP342x library, a compilation issue is raised:
Arduino15\packages\STM32\hardware\stm32l4xx\2016.9.16\libraries\Wire/Wire.h:51:5: error: 'i2c_instance_e' does not name a type

 i2c_instance_e p_i2c_instance; 

 ^

To correct this, #include "twi.h" should be made in the wire.h instead of wire.cpp.

RNG and other functions are not available

See http://stm32duino.com/viewtopic.php?f=3&t=1569&p=20222#p20222

RNG and possibly other features should be enabled / compiled into the static lib if they don't increase RAM usage

e.g.

https://github.com/stm32duino/Arduino_Core_STM32L4/blob/d2379b2bfe9c685b5dd814fa6284c7fc7facdd5e/system/libstm32l4/include/stm32l4xx_hal_conf.h#L83

Class inconsistencies in the Serial mappings

In variants/STM32L476RG_Nucleo/variant.cpp:

UARTClass Serial(USART2_E);    //available on PA2/PA3
UARTClass Serial1(USART1_E);   //available on PA9/PA10
USARTClass Serial2(USART2_E);  //available on PA2/PA3
USARTClass Serial3(UART4_E);   //available on PA0/PA1

Why using UARTClass for Serial and Serial1?
Why using USARTClass for Serial3?