Commit Graph

24 Commits (35c9e7a5adb9a83521dc4c9b533271b9809f3db6)

Author SHA1 Message Date
jeromecoutant c96eb2cd0e STM32 rename TOOLCHAIN_ARM_STD into TOOLCHAIN_ARM 2020-05-15 10:41:28 +02:00
jeromecoutant 303752ad84 STM32 remove all TOOLCHAIN_ARM_MICRO 2020-05-15 09:37:40 +02:00
Kevin Bracey fb6aa3ef4f Clean up ARM toolchain heap+stack setup in targets
ARM Compiler 6.13 testing revealed linker errors pointing out
conflicting use of `__user_setup_stackheap` and
`__user_initial_stackheap` in some targets. Remove the unwanted
`__user_initial_stackheap` from the targets - the setup is
centralised in the common platform code.

Looking into this, a number of other issues were highlighted

* Almost all targets had `__initial_sp` hardcoded in assembler,
  rather than getting it from the scatter file. This was behind
  issue #11313. Fix this generally.
* A few targets' `__initial_sp` values did not match the scatter
  file layout, in some cases meaning they were overlapping heap
  space. They now all use the area reserved in the scatter file.
  If any problems are seen, then there is an error in the
  scatter file.
* A number of targets were reserving unneeded space for heap and
  stack in their startup assembler, on top of the space reserved in
  the scatter file, so wasting a few K. A couple were using that
  space for the stack, rather than the space in the scatter file.

To clarify expected behaviour:

* Each scatter file contains empty regions `ARM_LIB_HEAP` and
  `ARM_LIB_STACK` to reserve space. `ARM_LIB_STACK` is sized
  by the macro `MBED_BOOT_STACK_SIZE`, which is set by the tools.
  `ARM_LIB_HEAP` is generally the space left over after static
  RAM and stack.
* The address of the end of `ARM_LIB_STACK` is written into the
  vector table and on reset the CPU sets MSP to that address.
* The common platform code in Mbed OS provides `__user_setup_stackheap`
  for the ARM library. The ARM library calls this during startup, and
  it calls `__mbed_user_setup_stackheap`.
* The default weak definition of `__mbed_user_setup_stackheap` does not
  modify SP, so we remain on the boot stack, and the heap is set to
  the region described by `ARM_LIB_HEAP`. If `ARM_LIB_HEAP` doesn't
  exist, then the heap is the space from the end of the used data in
  `RW_IRAM1` to the start of `ARM_LIB_STACK`.
* Targets can override `__mbed_user_setup_stackheap` if they want.
  Currently only Renesas (ARMv7-A class) devices do.
* If microlib is in use, then it doesn't call `__user_setup_stackheap`.
  Instead it just finds and uses `ARM_LIB_STACK` and `ARM_LIB_HEAP`
  itself.
2019-10-23 14:53:49 +03:00
jeromecoutant d919498745 STM32: common cmsis.h and device.h 2019-05-27 16:27:41 +02:00
deepikabhavnani 0dc5561991 Guard RAM start and size defines 2019-02-28 19:54:38 -06:00
deepikabhavnani b598dc1f46 Target_STM: Add ARM_LIB_STACK and ARM_LIB_HEAP section
Instead of user defined symbols in assembly files or C files,
use linker scripts to add heap and stack - this is inconsistent
with ARM std linker scripts
2019-02-28 19:54:28 -06:00
Deepika e522c4691e Target_STM:_sbrk updated to use limits from linker files no need to set defines
_sbrk uses the exports from linker file __end and __HeapLimit to allocate memory
in heap. Linker scripts were updated accordingly to set the limits.
2019-02-19 15:49:49 -06:00
Przemyslaw Stekiel 58f6bf7292 [STM] Support boot stack size configuration option 2019-01-08 15:32:06 +01:00
Deepika bf1a2c8485 [ST]: Fix alignment of execute region to 8-byte boundary in ARM linker files
--legacyalign, --no_legacyalign are deprecated from ARMC6 compiler, in order to
remove deprecated flags all linker files should strictly align to 8-byte boundary
2018-10-09 14:47:14 -05:00
bcostm 7097e07b62 stm32 ticker: typo corrections 2018-07-11 14:43:36 +02:00
bcostm d8e839a789 stm32 ticker: change license 2018-07-11 14:43:16 +02:00
bcostm 32031cbab3 stm32 ticker: rename hal_tick.h in us_ticker_data.h 2018-07-11 14:42:44 +02:00
bcostm fbd7a97e19 stm32 ticker: rename macro and update ST HAL Tick functions
- rename TIM_MST_16BIT in TIM_MST_BIT_WIDTH in order to use it directly in ticker info structure
- change HAL_InitTick() and HAL_GetTick()
2018-07-11 14:39:42 +02:00
bcostm b087390a1a Remove HAL_TICK_DELAY (no more used) 2018-06-05 16:53:40 +02:00
bcostm ccf71f0360 F3 ST CUBE V1.9.0: fix build errors with legacy macros 2018-05-07 10:58:49 +02:00
bcostm d0f8def2d7 F3 ST CUBE V1.9.0 2018-05-07 10:58:49 +02:00
jeromecoutant e8e4af3c7a DISCO_F303VC : add IAR files 2018-02-08 14:25:45 +01:00
bcostm 9f86a32baf Add freeze timer on debug for all STM32 devices
This is a continuation of the work done on the STM32F401xE devices only.
2017-09-18 13:31:46 +02:00
Jimmy Brisson 15a9a0382b Enable Compiling with ARMC6 across all targets
remove duplicate sys.cpp
2017-09-11 13:20:32 -05:00
Sam Grove 72de85c62f Merge pull request #4417 from monkiineko/master
STM32: Fix 32-bit us ticker interrupt scheduling
2017-06-06 19:59:52 -05:00
Bradley Scott 260378e774 STM32: Fix 32-bit us ticker interrupt scheduling
For STM32 targets using a 32-bit timer for the microsecond ticker, the
driver did not properly handle timestamps that are in the past.  It
would just blindly set the compare register to the requested timestamp,
resulting in the interrupt being serviced up to 4295 seconds late
(i.e. after the 32-bit timer counts all the way around to hit the
timestamp again).

This problem can easily be reproduced by creating a Timeout object
then calling the timeout's attach_us() member function to attach a
callback with a timeout of 0 us.  The callback will not get called for
over 2147 seconds, and possibly up to 4295 seconds late if no other
microsecond ticker events are getting scheduled in the meantime.

Now, after the compare register has been set, the timestamp is checked
against the current time to see if the timestamp is in the past, and
if so, the compare event is manually set.

NOTE: By checking if the timestamp is in the past after configuring the
capture register, we ensure proper handling in the case where the timer
updates past the timestamp while setting the capture register.
2017-06-01 12:52:03 -04:00
Bartek Szatkowski b97ffe8fdc CMSIS5: Replace target defined NVIC_Set/GetVector with CMSIS implementation 2017-05-30 18:55:51 +01:00
Bradley Scott 2f73d3b4a7 STM32F3: Remove dependence upon a specific flash vector table location
The STM32F3 cmsis_nvic code is currently checking for a specific flash
address when determining if the vector table is in flash or RAM.  By
changing the test to instead see if the vector table base is NOT set to
the RAM address, it simplifies the code, and removes the dependency on
the flash vectors being located at a specific address.  This becomes
important when adding a custom boot loader, which requires that the
flash vector table location in the mbed project be at a different
address.
2017-05-15 14:20:50 -04:00
adustm 703386d443 STM32F303xC folder struct 2017-01-27 19:30:27 +01:00