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.
Added an #ifndef directive to the __MBED_CMSIS_RTOS_CM and __CMSIS_RTOS macro definitions in order to prevent "Incompatible redefinition of macro" warnings from the online compiler.
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
* Dont exclude tests from magical lists
* update default toolchain locations for windows pointing to latest supported versions
* Fixing build loop in build_release.py
* Fixing incorrect target name in release script, preventing traceback in this case
* Breaking up the uploading of build/test results.
It defaults to 1000 'projectRuns' per POST call, though this can be
modified via the '-l' parameter when invoking 'add-project-runs'.
* remove default path to GCC. Setting takes priority to PATH so this breaks linux and Mac
* revert is_supported chages in favor of alternative command line option
- Allows threads to started separately from when they are declared,
avoiding the need to dynamically allocate threads at runtime.
- Allows multiple threads to join without forceful termination. Allowing
threads to synchronize on cleanup.
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
Martin Kojtal
Mihail Stoyanov
Sam Grove
Russ Butler
Kevin Bracey
Anna Bridge
Neil Thiessen
Russ Butler
Jimmy Brisson
Christopher Haster
Jerome COUTANT
Adam Green
Bartosz Szczepanski
Bogdan Marinescu