Pinout comparison between NuMaker-M467HJ and NuMaker-IoT-M467 boards:
1. UNO are unchanged
2. LEDs are unchanged
3. Buttons are unchanged, except button names
4. NuMaker-M467HJ has HBI but NuMaker-IoT-M467 does
5. NuMaker-M467HJ doesn't have ESP8266 but NuMaker-IoT-M467 does
6. SDHC are unchanged
Some M460 chips don't support AES/SHA/ECC/RSA H/W.
Make them removable from mbedtls H/W port through '"target.macros_remove": ["MBEDTLS_CONFIG_HW_SUPPORT"]'.
1. Crypto RSA H/W supports 1024/2048/3072/4096 key bits. Fall back to software implementation for other key bits.
2. For decrypt, if MBEDTLS_RSA_NO_CRT isn't defined, go CRT, or normal.
3. For decrypt, when blinding (f_rng != NULL), enable SCAP mode.
4. Recover from Crypto RSA H/W failure:
(1) Enable timed-out wait to escape from RSA H/W trap
(2) On RSA H/W timeout, stop this RSA H/W operation
(3) Fall back to S/W implementation on failure
NOTE: RSA 4096 key bits can fail with default mbedtls configuration MBEDTLS_MPI_MAX_SIZE.
Enlarge MBEDTLS_MPI_MAX_SIZE to 1024 or larger if this feature is required.
NOTE: Fixed in BSP RSA driver, for non-CRT+SCAP mode, temporary buffer for MADDR6 requires to be key length plus 128 bits.
NOTE: Fixed in BSP RSA driver, DMA buffer must be 4-word aligned, or RSA H/W will trap.
1. Prepare crypto common code
2. Support list
- SHA
- ECC
NOTE: AES/RSA are to support in other works
NOTE: Compared to M487, M467's SHA supports context save & restore (DMA Cascade mode) and so no software fallback is needed.
NOTE: M467's ECC, following M487, goes partial-module replacement and it can just improve primitives e.g. point addition/doubling by 2X,
and cannot improve high level point multiplication because MbedTLS doesn’t open it.
To improve performance best, full-module replacement is needed.
NOTE: Continuing above, add support for Montgomery curve
1. For GCC, support multi-block .data/.bss initialization
2. HyperRAM is mapped to two regions: 0x0A000000 and 0x80000000
According to default system address map, 0x0A000000 is located at 'Code' region and 0x80000000 at 'RAM' region.
With MPU enabled on Mbed OS, 'Code' region is write-never and 'RAM' region execute-never.
0x80000000 is chosen because 'RAM' regioin is naturally for HyperRAM.
3. Configurable multi-function pins for HBI
4. To locate code/data at external HyperRAM:
- Specify __attribute__((section(".text.nu.exthyperram"))) for RO/.text/readonly section type
Invoke mbed_mpu_manager_lock_ram_execution()/mbed_mpu_manager_unlock_ram_execution() to run HyperRAM code
- Specify __attribute__((section(".data.nu.exthyperram"))) for RW/.data/readwrite section type
- Specify __attribute__((section(".bss.nu.exthyperram"))) for ZI/.bss/zeroinit section type
5. Add readme
1. Based on alpha version BSP (85564a2716548e7b6d6a79a490c6d94a24cf9bcf)
2. Continuing above, tweak BSP:
(1) Add EPWM_ConfigOutputChannel2() to enable below 1Hz and below 1% duty cycle for PWM output (m460_epwm.h/c).
(2) Add dummy RTC_WaitAccessEnable() for consistency with previous ports (m460_rtc.h).
3. Target NuMaker-M467HJ V0.1 board temporarily
4. Support Arduino UNO form factor for NUMAKER_IOT_M467 target
5. Enable export to Keil/IAR project
- tools/arm_pack_manager/index.json
- tools/export/iar/iar_definitions.json
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.
Trying to inherit the STM32F412xE target makes the linker fail, since
__CRASH_DATA_RAM_START__ is not present. Comparing LD scripts with the
STM32F412xG (which has active targets) it seems that the xE variant has
missed some updates somewhere. Since the LD scripts are otherwise
identical, copying the (working) ones from STM32F412xG seems to do the
trick.
Also added flash_data.h which was missing and needed here and there
(copied from xG and updated to fit the xE flash layout).
The functions smsc9220_receive_by_chunks and smsc9220_send_by_chunks are
supposed to implement receiving and sending packets by chunks. However,
the functions SMSC9220_EMAC::low_level_input and SMSC9220_EMAC::link_out,
which call them respectively, already require or assemble the full packet.
Also, smsc9220_receive_by_chunks doesn't implement the "chunks" part.
This commit renames the functions to smsc9220_receive_packet and
smsc9220_send_packet. The functions now do their operations by word
instead of by bytes. The functions SMSC9220_EMAC::low_level_input and
SMSC9220_EMAC::link_out already handle allocation, continuity and word
alignment of the packet buffer.
The function smsc9220_receive_by_chunks loads data from the Ethernet port.
It is expected to return the Ethernet frame without the 4 CRC bytes.
However, it is required to call the Ethernet data port register (32-bit)
an amount equal to the number of frame words (including the 4 CRC bytes)
to pop all frame words. The current code doesn't call the register for the
last word (which has CRC data). This causes subsequent calls to have this
missed word at the beginning. The impact of this is huge as the high level
API is getting fed wrong data. The fix adds one additional call to the data
port register.
Use uint16_t variables for i2c slave_rx_buffer_size and slave_rx_count
variables. This allows to receive more than 255 bytes in slave mode. The
bytes are received one by one in slave mode so there are no hardware
limitations forcing a 1 byte rx count limit.
The HAL gpio_irq_api stores object IDs, which serve as a form of context
for the dispatch of the interrupt handler in the drivers level
InterruptIn Class. The way this is achieved is that the InterruptIn
Class casts its address to uint32_t, which is stored as the ID.
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 InterruptIn 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.
By default, HAL functions (HAL_SPI_TransmitReceive_IT/HAL_SPI_Transmit_IT/HAL_SPI_Receive_IT) assume that SPI is disabled between function invocation.
It's needed to set transfer size (CR2 register), that can be modified only if SPI disabled. But `stm32_spi_api.c` keeps SPI enabled after initialization.
This commit adds helper code for STM32H7 (SPI_IP_VERSION_V2) that disables SPI before HAL_SPI_TransmitReceive_IT/HAL_SPI_Transmit_IT/HAL_SPI_Receive_IT
and after end of transaction for HAL API compatibility.
Update SPI logic to process 16 bit words in the same way by sync/async,
3/4 wires modes:
- fix 3-wire synchronous transmission to move 2 or more bytes between buffer and
SPI register per word tarnsmission
- fix 4-wire synchronous transmission to move 2 or more bytes between buffer and
SPI register per word tarnsmission
[Warning] serial_device.c@657,41: comparison of different enumeration types ('PinName' and 'UARTName') [-Wenum-compare]
[Warning] serial_device.c@666,41: comparison of different enumeration types ('PinName' and 'UARTName') [-Wenum-compare]
[Warning] serial_device.c@675,41: comparison of different enumeration types ('PinName' and 'UARTName') [-Wenum-compare]
[Warning] serial_device.c@676,41: comparison of different enumeration types ('PinName' and 'UARTName') [-Wenum-compare]
[Warning] serial_device.c@644,41: comparison of integer expressions of different signedness: 'PinName' and 'enum <anonymous>' [-Wsign-compare]
[Warning] serial_device.c@644,41: comparison between 'PinName' and 'enum <anonymous>' [-Wenum-compare]
[Warning] serial_device.c@653,41: comparison of integer expressions of different signedness: 'PinName' and 'enum <anonymous>' [-Wsign-compare]
[Warning] serial_device.c@653,41: comparison between 'PinName' and 'enum <anonymous>' [-Wenum-compare]
[Warning] serial_device.c@662,41: comparison of integer expressions of different signedness: 'PinName' and 'enum <anonymous>' [-Wsign-compare]
[Warning] serial_device.c@662,41: comparison between 'PinName' and 'enum <anonymous>' [-Wenum-compare]
[Warning] serial_device.c@663,41: comparison of integer expressions of different signedness: 'PinName' and 'enum <anonymous>' [-Wsign-compare]
[Warning] serial_device.c@663,41: comparison between 'PinName' and 'enum <anonymous>' [-Wenum-compare]
[Warning] stm32g4xx_hal_hrtim.c@1817,21: equality comparison with extraneous parentheses [-Wparentheses-equality]
[Warning] stm32g4xx_hal_hrtim.c@1821,21: equality comparison with extraneous parentheses [-Wparentheses-equality]
[Warning] stm32g4xx_hal_hrtim.c@2461,21: equality comparison with extraneous parentheses [-Wparentheses-equality]
[Warning] stm32g4xx_hal_hrtim.c@2465,21: equality comparison with extraneous parentheses [-Wparentheses-equality]
[Warning] stm32g4xx_hal_hrtim.c@6600,21: equality comparison with extraneous parentheses [-Wparentheses-equality]
[Warning] stm32g4xx_hal_hrtim.c@7162,21: equality comparison with extraneous parentheses [-Wparentheses-equality]
[Warning] stm32g4xx_hal_hrtim.c@7166,21: equality comparison with extraneous parentheses [-Wparentheses-equality]
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]
Fix the following issues in TF-M to avoid emergence in the future:
1. Enable initial stack not located in SRAM bank0
On reset, only SRAM bank0 is enabled. And SRAM bank1/2 will be enabled in immediately following SystemInit().
When initial stack is located in SRAM bank1/2, we will meet trouble because SystemInit() itself needs to use initial stack.
To conquer the dilemma, we add preceding code in front of original Systeminit(), which is responsible for enabling SRAM bank1/2 and guarantees no using initial stack.
2. Fix sector maps of internal/external (SDH) Flash are incompatible, caused by TF-M's MCUboot port.
This is done by adapting external (SDH) Flash sector size to internal Flash's.
3. Enlarge firmware upgrade scratch size. There are two advantages:
(1) Get around MCUboot limit which requires scratch size not smaller than image trailer size
(2) Improve wear leveling for the scratch area
1. In TF-M, enlarge ITS max asset number/size
NOTE: RSA key size is larger
2. In TF-M, enlarge mbedtls dedicated heap
NOTE: RSA algorithm needs more memory.
NOTE: psa_aead_decrypt() (for mbedtls_ssl_read()) needs memory proportional to data size.
a "else" was missing for
uint32_t i2c_get_pclk(I2CName i2c)
if (i2c == I2C_1) {
else if (i2c == I2C_2) {
else if (i2c == I2C_3) {
else {
error("I2C: unknown instance");
for which the DP pin remained forced low after the reenumerate sequence
(low for 10ms) instead of being reconfigured as an input (PullNone).
Signed-off-by: David Douard <david.douard@sdfa3.org>