Reverting the DEFAULT_STACK_SIZE changes in cmsis.oh.h and adding
changes to RTOS_x tests, to create threads with the neccessary reduced
stack sizes for these targets.
The mcu STM32L053C8 seems to have a problem in the RCC - LSE hardware
block. The Disco_L053 don't have a 32kHz crystal connected to LSE port
pins in contrast to NUCLEO_L053.
During initialization the HAL tests if it can start the LSE oscillator.
The Flag LSERDY in RCC_CSR is set to 1 by RCC clock control when the
oscillator runs stable. Without a crystal the flag shouldn't be set and
the HAL trys to start the internal LSI oscillator.
But the flag is always set to 1 also without a crystal. That's why the
RTC doesn't start.
Stack should be 8 byte aligned on ARM.
Fix the automatic correction of the alignment in rt_init_stack,
and make sure that all stacks are aligned by the compiler.
- Adding an option to print a matrix similar to build.py -S with targets
and supported IDEs
- Adding an option to write README.md in workspace_tools/export
Decreasing OS_SCHEDULERSTKSIZE to 112 bytes solves the problem of the
failed test RTOS_3 (Semaphore resource lock).
The test itself was successfull but the final printf failed.
With the reduced stacksize now every test is OK.
There exists an inconsistency between official STM schematic of Nucleo
boards and the existing hardware. Each board should have an 8MHz
external clock source. That is not the case. At some boards the solder
jumper is existing and with that the external clock source. At some
other boards the solder jumper is not available. The Nucleo_F302 should
run with 72MHz but that is only possible with an external clock source.
Because of a missing solder jumper it runs only with the internal clock
source, and that's why only with 64MHz.
In case of off-line compiler, there is no problem about the frequency setting processing.
But in case of online compiler, the frequency setting processing will be error.
So, modify frequency setting processing of SPI to pass in online compiler.
Issue originally reported on mbed site here:
https://developer.mbed.org/questions/5695/FRDM-KL05z-hardfault-when-compiled-with-/
The RAM base address was incorrectly set to the beginning of RAM
instead of at a 0xC0 byte offset to reserve room for the interrupt
vectors. Without this fix, the global variables and the interrupt
vectors were occupying the same space in RAM once the user enabled the
timer interrupt.
The user who originally reported the issue on the mbed site has tested
this fix and verified that it corrected the hard fault issue that they
were encountering.
ohagendorf
Per Kristian Gjermshus
Martin Kojtal
Olivier Martin
Olaf Hagendorf
albert361
Masao Hamanaka
Toyomasa Watarai
Adam Green
GustavWi
bcostm
Przemek Wirkus