NominalPrescaler value needs to be as high as possible to ensure a good approximation of the target CAN speed.
Previous usage of macro IS_FDCAN_DATA_TSEG1 refers to (unsupported by Mbed ) FDCAN CAN controller settings and leads to too low prescaler values.
Usage Macro IS_FDCAN_NOMINAL_TSEG1 yields optimum results.
See also correct macro usage in line #158.
Detected with NUCLEO_G474RE build:
[Warning] stm32g4xx_hal_fdcan.h@1325,84: comparison is always true due to limited range of data type [-Wtype-limits]
[Warning] stm32g4xx_hal_fdcan.h@1331,46: comparison of integer expressions of different signedness: 'int' and 'unsigned int' [-Wsign-compare]
[Warning] stm32g4xx_hal_fdcan.h@1331,65: comparison of integer expressions of different signedness: 'int' and 'unsigned int' [-Wsign-compare]
[Warning] stm32g4xx_hal_fdcan.h@1325,61: comparison of integer expressions of different signedness: 'int' and 'unsigned int' [-Wsign-compare]
[Warning] stm32g4xx_hal_fdcan.h@1325,84: comparison of integer expressions of different signedness: 'int' and 'unsigned int' [-Wsign-compare]
The HAL can_api stores an array of IDs in order to dispatch interrupts
to the correct CAN object. The drivers level CAN Class casts a pointer
to itself to an uint32_t, which is stored as the ID and then cast back
to a CAN * in order to call the correct handler. This results in
compilation failure when the size of an object pointer is greater than
uint32_t, for example when building on a PC for unit testing.
In order to allow Unit Testing of the CAN Class, we replace the use of
uint32_t with uintptr_t (type capable of holding a pointer), which
allows portability and expresses intentions more clearly. In aid of this
latter goal, we also replace the use of the name "id" with "context",
to improve clarity. These are addresses of the context related to that
callback.
As per STM32H7-series reference manuals:
"Up to 64 filter elements can be configured for 29-bit extended IDs."
This commit fixes a bug which prevented receiving CAN-messages
with extended IDs.
Add license identifier to files which Arm owns the copyright to,
and contain either BSD-3 or Apache-2.0 licenses. This is to address
license errors raised by scancode analysis.
With tickless mechanism hsem can be used for quite a long time
(time to set up PLL clock).
Also, if hsem is held to long, then this is not the current core which is faulty,
but probably the other (the one which hold the HSEM)
Add 2 targets for DISCO_H747I dualcore:
* DISCO_H747I -> for CM7 core
* DISCO_H747I_CM4 -> for CM4 core
Current restrictions:
* TICKLESS deactivated
* DeepSleep not supported (DeepSleep wrapped to sleep)
Warning: use of the same IP (example I2C1) by both core at the same time is not prevented,
but is strongly not recommended.
Some Hardware Semaphore are use for common IP, to manage concurrent access by both cores: Flash, GPIO, RCC.
Warning: Drag and drop of binary to DISCO_H747I will flash CM7.
In order to flash CM4, one can use STM32 CubeProgrammer tool.
chdelfs
Jerome Coutant
Martin Kojtal
Hari Limaye
Samu Ampio
Mohammed Mubeen
Mohammed Mubeen
Cindy Li
reme
Martino Facchin
Harrison Mutai
m-ecry
Martin Eckardt
Maarten de Klerk
Przemyslaw Stekiel
Alexandre Bourdiol
Russ Butler
bcostm
Martin Kojtal