Added CAN API support for NUCLEO_L476RG target.
"stm32l476xx.h" file was changed to avoid compilation errors.
Change-Id: Ifadf7048f6c72c0311ec915e47ce2190460ede68
Added CAN API support for DISCO_L476VG target.
*stm32l476xx.h* file was changed to avoid compilation errors.
NOTE: MBED_29 or MBED_30 cannot be tested on this platform because CAN pins are
soldered to USB, GYRO and others.
Change-Id: I2e85bd36dc45872b1ab617f072de98164f2c96f8
We're ensuring target and host start-up sync here in 2 ways:
1) adding a delay on host side to make sure the serial
initialization can happen before sending a character is sent to target
2) in case of serial_nc_rx_auto.py test, we're sending a
first character S which will trigger the move from rx+tx
to NC+rx.
This should avoid any crossing case due to HSOT being faster than target or vice-versa
During initialization phase of the 2 NC serial tests,
there is a character being sent from host to target,
based on MBED_HOSTTEST_START. The problem is that
the target firmware then creates a "new" serial on the
same serial interface. the new or should, or at least may,
induce a reset of the IP, so that the character sent by host
would be lost. So we're moving the new earlier.
the real testing part happens later, to check the next
character is not received or sent.
- Resetting in LPCXpresso IDE did not reset the LCD controller which
sometimes could cause strange behaviour
- The ROM_LAT bit in the MATRIXARB register must be set in order to
prevent a HardFault when debugging
- The change of compiler in LPCXpresso IDE to ARM launchpad GCC5 was
causing build errors due to multiply defined timeval symbol.
- The exporters for LPCXpresso IDE did not set the FPU_PRESENT define
for assembler, only for c/c++. This caused very strange behaviour
in the RTOS code (e.g. timeouts no longer working, context switches
failing etc.)
We need to remove *can_api.c* file accordingly to new directory structure.
Without that we can't compile any CAN mBed test.
Change-Id: I3d4f798ad75ec1b4c4a1d7ed877e71b7db6bf60f
Added CAN API support for NUCLEO_F302R8 target.
*stm32f302x8.h* file was changed to avoid compilation errors.
Change-Id: Ia4ee8a90fe3f0ad6955dde21e78ea4a6c05e4fcd
Added CAN API support for NUCLEO_F303K8 target.
*stm32f303x8.h* file was changed to avoid compilation errors.
Change-Id: If093c84f19c5a5ef68938af4653a25271c1108ba
Added CAN API support for NUCLEO_F303RE target.
*stm32f303xe.h* file was changed to avoid compilation errors.
Change-Id: Ia6519c982261d43165dbce73cab7cfc0617474e2
Added CAN API support for NUCLEO_F334R8 target.
*stm32f334x8.h* file was changed to avoid compilation errors.
Change-Id: Ic7b3273ffe24940ecdc189d2566a6a7f66825ce6
Added CAN API support for NUCLEO_F042K6 target.
"stm32f042x6.h" file was changed to avoid compilation errors.
Change-Id: I9622a233775fc6834201a322740bf5026244d50e
Added CAN API support for NUCLEO_F072RB target.
*stm32f072xb.h* file was changed to avoid compilation errors.
Change-Id: I9da75fde29fd19f0326d554acc1dbb5386b08317
Added CAN API suport for NUCLEO_F091RC target.
*stm32f091xc.h* file was changed to avoid compilation errors.
Change-Id: I9207575a0e2ad0f8e3a4bb78eb23d1e7b4a94171
we changed the sequence of ROM section to "<ro code> <ro data>" when compiled with the IAR.
When the ROM area is large, PC could not jump properly in the program area.
The other development environment of this sequence ("ro code, ro data").
https://github.com/mbedmicro/mbed/pull/1702
In this PR, rtx has updated, the macro into the code were changed.
However, by this macro, the process of task generation in Cortex-A9 can no longer be run.
So, we solve the task generation problem by changing the macro into Tread.cpp again.
* [STM32F4] Get PCLK1 clock and set initial CAN frequency
CAN bus opperates on APB1 peripheral clock due to that we need to get PCLK1 freq
in *can_frequency()* function to properly calculate CAN speed and reconfigure
BS1, BS2, SJW bits.
Also to fully communicate with other ST platform we set the initical CAN
frequency to 100kb/s to be able to work with the slowest platform which supports
CAN, which is NUCLEO_F303K8 (APB1 is 32MHz).
Change-Id: I10af3aa8d715dd61c9d1b216ef813193449fecbd
* [STM32F4] Fix for CAN2 interrupt index
CAN2 interrupt index was wrong leading to not properly registering interrupt.
Having this fix allow us to pass MBED_30 test.
Change-Id: I33f9ca7c81286f7746a8f8352619e213bdf9756a
With PR #1707 all STM32F4 targets with UART4 and UART5 are broken, a several typos in function definition.
Seems to be a bug in STM32Fcube HAL, not only in the (older) mbed versin but also in current version
* [STM32F1 F4] Fix#1705 MBED_37
The transmit data register needs to be flushed at the initialisation of
the uart.
In case previous transmission was interrupted by a uart init, uart may
contain a char that will be transmitted at the next start.
This is the case in MBED_37 test (serial_auto_nc_rx).
The MCU is writting {{start}}\n
At the moment of the \n the main program is handling 'new serial'. The
next time the main program is handling a printf, the previous \n is
still present in the uart->DR register and is transmitted.
This cannot happen anymore with this commit
* [STM32_F1] Fix#1705 MBED_37 by resetting the uart
svastm
Russ Butler
Christopher Haster
Martin Kojtal
Vincent Coubard
Bartosz Szczepanski
Laurent Meunier
Steven Cooreman
Anders Lindvall
Mihail Stoyanov
Sam Grove
Mihail Stoyanov
Mahadevan Mahesh
TomoYamanaka
ohagendorf
adustm