- 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.)
Routines using __disable_irq and __enable_irq had the effect of
enabling interrupts if called with interrupts disabled.
Some versions of __disable_irq do not return old status to restore it.
Change to use the critical section helper functions instead.
This includes a generic critical section implementation. This
implementation also allow a user to start a critical section while
interrupts are already disabled.
per @c1728p9
Update the Callback class to handle a NULL thunk by returning 0
rather than trying to call the thunk. This fixes a crash that occurs
on some targets when the TX uart handler is not attached.
Background:
The K64F HAL uart implementation calls the TX interrupt handler
every time a uart interrupt occurs while the TX register is empty.
It does not check to see if the TX interrupt has been enabled.
This means that the TX interrupt can and typically does get
run on RX events. This causes a crash with the newer callback
code which did not (prior to this patch) support a NULL thunk.
- Adopt C++11 style template arguments, requires rename to Callback
- Add constructor for C style callback functions
- Add constructor for Callbacks
- Add static function for passing to C style callbacks
In repeating start scenarios, there was a bug in the I2C driver for
various NXP LPCxxxx parts which could allow an extra I/O from the
previous operation to leak through. The scenario I encountered which
triggered this bug went like so:
* The higher level application code would first do an I2C write that
doesn't send a stop bit (use repeating start instead.)
* The higher level application code would then issues an I2C read
operation which begin with a call to i2c_start().
* i2c_start() would clear the SI bit (interrupt flag) at the top of
its implementation.
* i2C_start() would then get interrupted right after clearing the SI
bit.
* While the CPU is off running the ISR code, the I2C peripheral
repeats the last byte written to I2CDAT and then sets the SI bit to
indicate that the write has completed.
* The ISR returns to allow the i2c_start() to continue execution.
* i2c_start() would then set the STA bit but it is too late.
* i2c_start() waits for the SI bit to be set but it is already set
because of the completed byte write and not because of the repeated
start as expected.
For me this bug would cause strange interactions between my ISRs and
the code using I2C to read from the MPU-6050 IMU. I would be getting
valid orientation data and then all of a sudden I would start receiving
what looked like random values but I think it was just reading from the
incorrect offset in the device's FIFO.
It appears that atleast one other person has seen this before but it
was never root caused since it required specific timing to reproduce:
https://developer.mbed.org/forum/bugs-suggestions/topic/4254/
This bug can be found in most of the NXP I2C drivers and this commit
contains a fix for them all. I however only have the LPC1768 and
LPC11U24 for testing.
My fix does the following:
* No longer clears the SI bit in the i2c_conclr() call near the
beginning of the i2c_start() function. It was this clear that
previously caused the problem as described above.
* The second part of the fix was to instead clear the SI bit after
the STA (start) bit has been set with the i2c_conset() call.
* The clearing of the SI bit should be skipped if there isn't an
active interrupt when first entering i2c_start(). If you clear
the SI bit when there isn't an active interrupt then the code
is likely to skip over the interrupt for the start bit which was
just sent and then allow the I2C peripheral to start sending the
slave address before it has even been loaded into the I2CDAT
register.
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
This path fixes issue #816.
Current value of TIM_MST->CNT is read in interrupt context only.
This avoids master timer overflow without SlaveCounter update.
Change-Id: I8e2ec02ce7539a4c044c7e3dfe6bedc9fcdf7736
This path fixes issue #816.
Current value of TIM_MST->CNT is read in interrupt context only.
This avoids master timer overflow without SlaveCounter update.
Change-Id: Iaaf7b9eb33aa8d8992e9354ca5e21bf01ec2413d
This path fixes issue #816.
Current value of TIM_MST->CNT is read in interrupt context only.
This avoids master timer overflow without SlaveCounter update.
Change-Id: Ie7a9bfce76990f85caa84264450d053604af33e5
Both STM32F0xx and STM32F1xx are using a 16-bit timer as a internal ticker
but the mBed ticker needs a 32-bit timer implementation, so the upper part
of that 32-bit timer is being calculated in software.
Software bug has been fixed where continous HIGH/LOW voltage levels
could be observerd for 65ms due to 16-bit timer overflow.
Now current value of TIM_MST->CNT is stored in cnt_val and is
updated in interrupt context only. This avoids master timer
overflow without SlaveCounter update.
This fix is only for platforms which already implements a 16-bit timer:
F103RB, F070RB, F030R8
Change-Id: I205c70ce155b373c6593ead93ade9ec38993f7f9
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
This was causing errors at my machine (for programs like MBED_10, RTOS_1):
Error[Li005]: no definition for "__semihost" [referenced from
semihost_api.o(mbed.a)]
[ERROR] Error[Li005]: no definition for "__semihost" [referenced from
semihost_api.o(mbed.a)]
Anders Lindvall
adustm
Sam Grove
Russ Butler
Kevin Bracey
Anna Bridge
Russ Butler
Jimmy Brisson
Christopher Haster
0xc0170
Adam Green
Bartosz Szczepanski
Rafal Kula
Mihail Stoyanov
Mihail Stoyanov