1. Update BSP CANFD driver
2. Notes for implementation
(1) Each CANFD instance supports two IRQ lines. Use only line 0. Line 1 is not used.
(2) For Rx disabling multiple filter handles,
1) Map all filter handles to filter handle 0
2) Use Rx FIFO 0 for filter handle 0
(3) For Rx enabling multiple filter handles,
1) Use Rx FIFO 0 for filter handle 0
2) Use Rx FIFO 1 for filter handle through first invoking can_filter()
3) Use dedicated Rx Buffer for other filter handles
NOTE: H/W supports mask on Rx FIFO 0/1 but not on dedicated Rx Buffer.
(4) For Tx, use only dedicated Tx Buffer. BSP CANFD driver doesn't support Tx FIFO/Queue.
(5) Support no CAN FD.
Fix bug where calling set_format in MBED (which calls serial_format) causes the CTRL register to become corrupt due to saving its initial value to a uint8_t when the register is 32 bit wide
Fix bug where calling set_format in MBED (which calls serial_format) causes the CTRL register to become corrupt due to saving its initial value to a uint8_t when the register is 32 bit wide
Limit NUCLEO_H723ZG toolchain to GCC_ARM only.
This is the only toolchain this target has been tested with yet.
Signed-off-by: Daniel Starke <daniel-email@gmx.net>
- add board specific EMAC setup to connectivity/drivers/emac/TARGET_STM/TARGET_STM32H7
- stm32h7_eth_init.c was derived from the NUCLEO-H743ZI2 code whilst comparing to the output of STM32CubeIDE
- complete board specific code in targets/TARGET_STM/TARGET_STM32H7/TARGET_STM32H723xG
- PeripheralPins.c and PinNames.h were created by targets/TARGET_STM/tools/STM32_gen_PeripheralPins.py
- ST ZIO connector pins in PinNames.h have been adapted from NUCLEO-H743ZI2
- CONSOLE_TX and CONSOLE_RX have been interchanged in PinNames.h to match the actual board layout
- startup_stm32h723xx.S was derived from startup_stm32h743xx.S
- stm32h723xg.ld was completely rewritten to match the actual MCU including:
- split heap support
- SRAM2 and SRAM4 support
- crash dump support
- proper use of DTCM as stack
- system_clock.c has been changed to support the maximal main clock speed of 550 MHz
- fix handling of HS in FS mode for the target board in targets/TARGET_STM/USBPhy_STM32.cpp
- add board definition to targets/targets.json and correct linker setup for the chip
Signed-off-by: Daniel Starke <daniel-email@gmx.net>
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.
Jasper Jonker
Martin Kojtal
Sadik.Ozer
Chun-Chieh Li
jmcloud
Jamie Smith
Augusto Zanellato
Leonard Chiang
Charles
grumpyengineer
Jerome Coutant
Martyx00
caodd
Yilin Sun
Deepak V. Shreshti
Jamie Smith
cyliangtw
Daniel Starke
Ahmet Alincak
chdelfs
Henrik Persson
Jason Reiss
Pavel S
Rami Elkhatib
YahyaTawil
Sadik.Ozer