ARMmbed
/
mbed-os
mirror of https://github.com/ARMmbed/mbed-os.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
5,971 Commits
52 Branches
336 Tags
624 MiB
Commit Graph

5971 Commits (d1ec4beabef320b48ec3cdad57e293ce7708f55f)

Author SHA1 Message Date
Martin Kojtal bd78f98496 Merge pull request #1750 from NXPmicro/dev_ksdk_2.0 
Fix for Issue#1740.
 2016-05-22 16:47:45 +01:00
Krzysztof Sitko db8595264a STM32F031K6 Missing UART_RX Pin Def 
PA3 on the STM32F031K6 can function as a USART1_RX pin.
 2016-05-20 12:58:36 -04:00
Bartosz Szczepanski fad2190225 [NUCLEO_F042K6] Added CAN support 
Added CAN API support for NUCLEO_F042K6 target.

"stm32f042x6.h" file was changed to avoid compilation errors.

Change-Id: I9622a233775fc6834201a322740bf5026244d50e
 2016-05-20 13:27:58 +02:00
Bartosz Szczepanski d140e9959a [NUCLEO_F072RB] Added CAN support 
Added CAN API support for NUCLEO_F072RB target.

*stm32f072xb.h* file was changed to avoid compilation errors.

Change-Id: I9da75fde29fd19f0326d554acc1dbb5386b08317
 2016-05-20 11:48:34 +02:00
Bartosz Szczepanski 8577163ca3 [NUCLEO_F091RC] Added CAN support 
Added CAN API suport for NUCLEO_F091RC target.

*stm32f091xc.h* file was changed to avoid compilation errors.

Change-Id: I9207575a0e2ad0f8e3a4bb78eb23d1e7b4a94171
 2016-05-20 11:48:33 +02:00
Bartosz Szczepanski f04377d889 Added CAN API for STM32F0xx family 
* STM32F0xx family have only one CAN bus

Change-Id: Id17fbfb825fabe04725a829a121300290f074919
 2016-05-20 11:26:55 +02:00
Toyomasa Watarai 3281f5fb9a [LPC812] Fix PwmOut conflict issue 
* Use conflict resolution register to set/clear output
 2016-05-20 13:40:02 +09:00
tomoyuki yamanaka 829b422a6d Bug fix for IAR support. 
We modified function definition for IAR support.
 2016-05-18 16:10:30 +09:00
Bogdan Marinescu bc063a3903 Moved target definitions to JSON format 
(long commit message ahead. Sorry about that, it can't be helped.)

This commit changs targets definition from Python to JSON format, as
part of the configuration mechanism implementation. There is a new file
under workspace_tools/ called "targets.json" which contains the target
definitions. "targets.py" remains, but becomes a wrapper on top of
"targets.json", with the same interface as before. This has the
advantage of not requiring code changes outside "targets.py".

Most of the JSON definitions of targets were automatically generated by a
script (available upon request since it doesn't make a lot of sense to
include it here), only those targets that had more than one parent in
the Python implementation were converted by hand. The target definitions
should be pretty self-explanatory. A number of things are different in
the JSON implementation (this is just a summary, check docs/mbed_targets.md
(also part of this PR) for a more complete description):

- "program_cycle_s" is now a value (as opposed to a function in the
Python implementation), since it only returned a number in all the
Python target implementations. The main definition that actually contains
some code (in class "Target") remains in target.py
- array values in "macros" and "extra_labels" can be modified
dynamically. Values can be added using "macros_add" and
"extra_labels_add" or removed using "macros_remove" and
"extra_labels_remove". This mechanism is available for all attributes
with a list type, but it's currently enabled only for "macros" and
"extra_labels" to keep things simple.
- "init_hooks"/"binary_hook" are now implemented in terms of a single
JSON key valled "post_binary_hook". The corresponding code is also in
"targets.py", under the various TargetCode classes (see for example
LPC4088Code in targets.py).

Just like in the Python implementation, a target can inherit from zero,
one or more targets. The resolution order for the target's attributes
follows the one used by the Python code (I used
http://makina-corpus.com/blog/metier/2014/python-tutorial-understanding-python-mro-class-search-path
as a reference for the implementation of resolution order).

This is obviously a very dangerous commit, since it affects all targets.
I tested compilation for a number of targets (K64F, LPC1768, NRF51822)
but there's definitely a lot more to be done in terms of testing.

I also tried to test in a different way: I wrote a script that imports the
old (Python) and the new (JSON) implementations and verifies that the
attributes in the old implementations exist and have the same values
in the new implementations (it also verifies that the attribute
resolution order is the same in the two implementations). If you're
interested, the script is here:

https://gist.github.com/bogdanm/c9d8cf34214109a4b9079befed6b3c0c

And the results of running the script are below (note that the script
outputs only the target names that were found to be problematic):

NRF51_MICROBIT_BOOT:
    Resolution order is different in old and new
        old: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110']
        new: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target']
    'extra_labels' has different values in old and new
        old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_BOOT', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT']
        new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BOOT', 'NRF51_MICROBIT']
    'macros' has different values in old and new
        old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC']
        new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC']
NRF51_MICROBIT:
    Resolution order is different in old and new
        old: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110']
        new: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target']
    'extra_labels' has different values in old and new
        old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110']
        new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NRF51_16K_S110', 'MCU_NORDIC_16K', 'MCU_NRF51_16K']
    'macros' has different values in old and new
        old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF_LFCLK_RC']
        new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_NRF_LFCLK_RC']
NRF51_MICROBIT_OTA:
    Resolution order is different in old and new
        old: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110']
        new: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target']
    'extra_labels' has different values in old and new
        old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_OTA', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT']
        new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_OTA', 'NRF51_MICROBIT']
    'macros' has different values in old and new
        old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC']
        new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC']
NOT OK: ['NRF51_MICROBIT', 'NRF51_MICROBIT_BOOT', 'NRF51_MICROBIT_OTA']

The reasons for the above output are subtle and related to the
extremely weird way in which we defined target data in the Python
implementation: we used both class attributes and instance attributes.
This can complicate resolution order quite a bit and those two levels
don't exist in JSON: there's only one attribute type (equivalent to
Python's instance attributes). To make that work, I had to change the
inheritance order of the above targets (that use multiple inheritance)
which in turn changed the order of some macros and extra_labels (and of
course the resolution order). No harm done: the values are the same,
only their ordering is different. I don't believe this causes any
problems for 'extra_labels' and 'macros'.

This method of testing has its limitations though; in particular, it
can't test the hooks. I'm opened to ideas about how to test this better,
but I think that we need to remember that this commit might break some
targets and keep an eye out for "weird errors" in the future.
 2016-05-17 21:42:55 +03:00
Mahadevan Mahesh e6e1f73599 Fix for Issue#1740. The latest SDK drivers for FTM & TPM has the fix for this issue 
This fixes issues seen when running FTM and TPM demos in certain modes

Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
 2016-05-17 12:03:14 -05:00
bcostm 315d143382 Change macro names for FORCE/RELEASE_RESET for UART4, 5, 6, 7 2016-05-17 16:46:31 +02:00
Martin Kojtal a1914e17f3 Merge pull request #1742 from ohagendorf/STM32F4xx_PR1707_bugfix 
[STM32F4xx] bugfix for PR #1707
 2016-05-17 14:42:31 +01:00
Martin Kojtal b77f84df32 Merge pull request #1747 from TomoYamanaka/master_branch 
Fixed a problem that can not be the task generation in Cortex-A9.
 2016-05-17 12:56:08 +01:00
TomoYamanaka 909c76f36c In IAR compile, change the sequence of the ROM section. (#1722) 
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").
 2016-05-17 12:39:47 +01:00
tomoyuki yamanaka bebc235ffb Bug fix of Serial in IAR compile 
We fixed bug of Serial in IAR complie.
We modified so as to have #if defined ( __ICCARM__ )  definition as well.
 2016-05-17 20:35:49 +09:00
tomoyuki yamanaka d0250bb09e Fixed a problem that can not be the task generation in Cortex-A9. 
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.
 2016-05-17 20:18:10 +09:00
ohagendorf 1be302b1b6 [STM32F4xx] bugfix for PR #1707 - more typos 
I found and corrected some more typos.
 2016-05-16 19:05:57 +02:00
Bartosz Szczepanski 840df6ccd7 [NUCLEO_L053R8] Fix issue #816 
NUCLEO_L053R8 is using a 16 bit timer as a internal ticker but the mBed ticker
needs a 32 bit timer, so the upper upart of that timer is being calculated in
software. Continous HIGH/LOW voltage levels were observerd for 65ms due to timer
overflow, so to narrow down the issue, it was decided to switch to 16 bit values
and glue them to get a 32 bit timer.

Change-Id: I54a06d5aa0f8ddabd8abc194470845a2509e0c55
 2016-05-16 13:41:53 +02:00
Bartosz Szczepanski 1d1f7ab133 [STM32F4] Clock and interrupt fixes (#1735) 
* [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
 2016-05-16 11:55:59 +01:00
ohagendorf 97d282eae1 [STM32F4xx] bugfix for PR #1707 
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
 2016-05-15 19:24:23 +02:00
adustm 7bd986845c [STM32F1 F4] Fix #1705 MBED_37 (#1707) 
* [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
 2016-05-13 15:50:13 +01:00
bcostm 13f0c1ff6f [NUCLEO_F746ZG] Add RTOS and MBED_A8 tests (#1728) 
* Add RTOS, MBED_A8 tests

* [NUCLEO_F746ZG] Add pins for MBED_A8 test
 2016-05-13 15:46:03 +01:00
Olaf Hagendorf a4c55293e0 minor change in doc string format in exporter.py (#1739) 2016-05-13 10:39:56 +01:00
adustm e5c1d37c25 [STM32F7] add FPU option for assembly compiling (needed for rtos library) 2016-05-13 11:19:07 +02:00
adustm dbb99d4eee NUCLEO_F746ZG] add this board to rtos 1-8 tests 2016-05-13 10:59:59 +02:00
Martin Kojtal 6483faedd2 Merge pull request #1734 from svastm/fix_adc_f746zg 
[STM32F7] Fix end of conversion
 2016-05-13 09:09:49 +01:00
svastm 62aca7515d [STM32F7] Fix end of analogin conversion 2016-05-12 10:09:54 +02:00
neilt6 a2bfca7527 [RTOS] Fixed osThreadGetState() 
Fixed regression that caused terminated threads to return an erroneous
state value instead of "inactive".
 2016-05-11 16:06:24 -06:00
Martin Kojtal 3210b40a91 Merge pull request #1729 from mbedmicro/release 
mbed lib v120
 2016-05-11 11:13:02 -05:00
0xc0170 3d988623d4 mbed lib revision - 120 2016-05-10 10:21:13 -05:00
0xc0170 1290925ad1 Build release - RZ_A1H iar removal 
There are issues with cmsis API, which were not ported to IAR.
 2016-05-10 10:21:09 -05:00
Martin Kojtal be6e09bec3 Merge pull request #1725 from 0xc0170/fix_ksdk_old_macro 
Target - backward compatibility KSDK 1.0 labels
 2016-05-09 15:12:13 -05:00
0xc0170 5681da0845 Target - backward compatibility KSDK 1.0 labels 
The extra_labels should not be removed, as it could break old sources or
mbed-lib or applications.
 2016-05-09 13:44:37 -05:00
Martin Kojtal 7b4f4fc40d Merge pull request #1715 from helmut64/L4heapsize 
Changed the heap size to the correct MCU heap size for SRAM1
 2016-05-09 12:35:10 -05:00
Martin Kojtal a97cf280f3 Merge pull request #1713 from BartSX/stm32f4_can 
[STM32F4 family] Assign CAN filter number properly
 2016-05-09 12:31:39 -05:00
Martin Kojtal 8ea1244a2e Merge pull request #1712 from BartSX/iar 
[STM32L4] Fix IAR section placement failed error
 2016-05-09 12:30:47 -05:00
Martin Kojtal ad75bdcde3 Merge pull request #1704 from adustm/stm32f1_cube_update 
[STMF1] Stm32f1_hal_cube update
 2016-05-09 12:26:22 -05:00
Martin Kojtal 15cfb8fe4a Merge pull request #1718 from 0xc0170/fix_rtos_idle 
gcc - use group for ld to resolve symbols from libraries
 2016-05-09 12:25:54 -05:00
0xc0170 58e47dc500 gcc makefile - use group for ld to resolve symbols from libraries 2016-05-09 12:06:33 -05:00
0xc0170 8681a8d53e gcc - use group for ld to resolve symbols from libraries 
This fixes problem we have seen with rtos_idle_loop. The symbols
was not resolved as order played a role in this case. Remove circular
dependencies member, as it should not be required anymore.
 2016-05-09 12:02:23 -05:00
Sam Grove c5b4c543c9 Merge pull request #1720 from 0xc0170/fix_rtos_macro 
RTOS - fix Cortex-M version - add macros required for new kernel
 2016-05-06 13:01:33 -05:00
0xc0170 9aee702b11 RTX - pull cmsis_os into rt_Timer 
This causing a warning in the rt_cmsis.c, as they use preprocessor
to redefine a type. A fix is to move the macro above, as it should not
change anything else. This should be removed, and use a cast, however I am
not fully familiar why they do this macro trick.
 2016-05-06 12:27:25 -05:00
0xc0170 def841979a RTOS - fix Cortex-M version - add macros required for new kernel 
2 new macros were introduced to capture changes in the kernel. We used toolchains/__init__
script to capture those, which is not in the sync with actual sources. This fix introduces
those macros in the source, rather than a script.

We will further eliminate those macros to be used outside of RTX kernel (c++ API).
 2016-05-06 11:50:21 -05:00
Martin Kojtal 84fc61c940 Merge pull request #1716 from neilt6/master 
[RTOS] Improved Error Functions
 2016-05-05 15:50:50 -05:00
neilt6 a484830587 [RTOS] Improved Error Functions 
Added error message to sysThreadError(), and improved os_error().
 2016-05-05 14:43:56 -06:00
Helmut Tschemernjak 324dd06216 Changed the heap size to the correct MCU heap size for SRAM1 2016-05-05 22:14:30 +02:00
Martin Kojtal 53b54323ba Merge pull request #1706 from LMESTM/fix_pwmout 
Fix pwmout for STM32F3
 2016-05-05 14:46:07 -05:00
Martin Kojtal 860fdd282b Merge pull request #1702 from 0xc0170/dev_rtos_update 
rtx update to v4.79
 2016-05-05 14:35:40 -05:00
0xc0170 cacf085e73 rtx - set task id prior rt_init_context 
This is a bugfix, which caused LPC1549 to fail (os_error). There was a fix
introduced to rtx mbed sources. For more information:
461403989c
 2016-05-05 13:49:47 -05:00
0xc0170 239c40eb62 RTX - os_error invokes mbed error() 2016-05-05 12:11:11 -05:00