Moved target from ../targets/cmsis/TARGET_STM folder to
../targets/cmsis/TARGET_STM/TARGET_STM32L1 folder as discussed with
0xc0170 (github.com/mbedmicro/mbed/pull/928). Renamed target from
NZ32ST1L to NZ32SC151. Details for board at
www.modtronix.com/nz32-sc151.html
Added stack checking methods to the Thread class for Cortex-M targets.
The stack memory size, currently free stack memory, and currently used
stack memory are calculated using the TCB. The maximum stack memory
usage is determined by filling the stack with a magic word, and finding
the high water mark.
The OS_TASKCNT is set to 6, could be more.
The OS_SCHEDULERSTKSIZE is set to 112, could also be more.
The OS_CLOCK is set to 72000000 which matches the description on https://developer.mbed.org/platforms/ST-Nucleo-F303RE/
Cheers
I am not sure if it's the right SP, but the basic blink code works.
What does the SP stand for? Stack pointer?
Also, if you could tell me where to look for the correct address, I would.
I looked in the reference manual and the programming manual that STM provides, with no luck.
Cheers
- Removed target alias from the EXPORT_MAP in targets.py as it didn't work
- Added copies of the LPC4088 target exporters
- Fixed flag issue in the gcc toolchain
- Changed defines in eth USBDevice, rpt and rtos to handle
TARGET_LPC4088_DM
This is a fix for issue #285. This fix is similar to that proposed by
@oresths in the original issue.
There is code in rt_init_stack() which compares the task_id against the
value of 1 before writing MAGIC_WORD to the bottom of the stack. This
is supposed to stop the write from occurring for the main thread but
svcThreadCreate() doesn't initialize the P_TCB's task_id field until
after rt_init_stack() is executed. If any dynamic memory allocation
has occurred before the main thread is started (from the standard C
startup code) then this write could overwrite data in that allocation.
This change:
* moves the task_id initialization in svcThreadCreate() to happen
before the call to rt_init_context() is made.
* cleans up some comments in svcThreadCreate() which appear to
reference older versions of the code which would automatically
allocate stack memory if size == 0.
* still keeps the call to rt_dispatch() occurring after the call to
rt_init_context() so that the task is not dispatched to the
scheduler until the task fields have been populated.
I stepped through the rt_init_stack() code on my mbedLPC1768 after this
change was made to make sure that the write of MAGIC_WORD is now
skipped.
-----------------------------------------------------------------------
(gdb) break HAL_CM.c:95
Breakpoint 1 at 0x482c: file ../../external/mbed/libraries/rtos/rtx/TARGET_CORTEX_M/HAL_CM.c, line 95.
(gdb) c
Continuing.
Note: automatically using hardware breakpoints for read-only addresses.
Breakpoint 1, rt_init_stack (p_TCB=0x10000774 <os_idle_TCB>, task_body=0x4899 <os_idle_demon>)
at ../../external/mbed/libraries/rtos/rtx/TARGET_CORTEX_M/HAL_CM.c:95
95 if (p_TCB->task_id != 0x01)
(gdb) p *p_TCB
$1 = {
cb_type = 0 '\000',
state = 1 '\001',
prio = 0 '\000',
task_id = 255 '\377',
p_lnk = 0x0 <_reclaim_reent>,
p_rlnk = 0x0 <_reclaim_reent>,
p_dlnk = 0x0 <_reclaim_reent>,
p_blnk = 0x0 <_reclaim_reent>,
delta_time = 0,
interval_time = 0,
events = 0,
waits = 0,
msg = 0x0 <_reclaim_reent>,
stack_frame = 0 '\000',
reserved = 0 '\000',
priv_stack = 128,
tsk_stack = 268437480,
stack = 0x100007a8 <idle_task_stack>,
ptask = 0x4899 <os_idle_demon>
}
(gdb) c
Continuing.
Breakpoint 1, rt_init_stack (p_TCB=0x10000120 <os_thread_def_main+16>, task_body=0x620d <__wrap_main()>)
at ../../external/mbed/libraries/rtos/rtx/TARGET_CORTEX_M/HAL_CM.c:95
95 if (p_TCB->task_id != 0x01)
(gdb) p *p_TCB
$2 = {
cb_type = 0 '\000',
state = 1 '\001',
prio = 4 '\004',
task_id = 1 '\001',
p_lnk = 0x0 <_reclaim_reent>,
p_rlnk = 0x0 <_reclaim_reent>,
p_dlnk = 0x0 <_reclaim_reent>,
p_blnk = 0x0 <_reclaim_reent>,
delta_time = 0,
interval_time = 0,
events = 0,
waits = 0,
msg = 0x0 <_reclaim_reent>,
stack_frame = 0 '\000',
reserved = 0 '\000',
priv_stack = 26968,
tsk_stack = 268467136,
stack = 0x100012a8,
ptask = 0x620d <__wrap_main()>
}
(gdb) n
97 }
When the p_TCB for ptask==__wrap_main() is encountered, the task_id
now has a value of 1 and the write of MAGIC_WORD on line 96 is
skipped.
This issue was originally reported on the mbed site:
http://developer.mbed.org/questions/5570/mbed-rtos-memory-utilization/
The cause of the 64k limitation is that even though the user can set a
stack size larger than 64k in the osThreadDef_t::stacksize 32-bit
field, this size is truncated to 16-bit when it is copied to
the priv_stack field in the OS_TCB structure.
This commit corrects that problem by making the OS_TCB::priv_stack
field 32-bit. Due to word alignment, this introduces another 2 bytes
of padding in the structure which I have made explicit with the
addition of the reserved2 field.
The tsk_stack field which follows priv_stack is referenced directly by
assembly language code responsible for context switching. This context
switching code used a fixed byte offset, TCB_TSTACK, to access this
tsk_stack field. I had to update the TCB_TSTACK definition in various
locations from 36 to 40 to account for the extra alignment padding and
increased size of the priv_stack field.
TESTING
* GCC_ARM - mbedLPC1768 and mbedLPC11U24
* Online mbed Compiler - mbedLPC1768 and mbedLPC11U24
NOTES: I had to change assembly language code that was specific to IAR
but I don't have that toolchain so those changes aren't tested.
They do however follow the same pattern as the tested GCC
modifications.
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.
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.
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.
- Change default setting of CMSIS-RTOS RTX for Cortex-A9 to align with Cortex-M.
- Change the interrupt priority of Ether driver to align with other drivers.
Original STM32Cube F4 driver sets SYSCLK for STM32F429 to 16MHz. This
adds a 168MHz and 180MHz configuration to system_stm32f4xx.c generated
by STM32CubeMX code generator. The rtos clock configuration is changed
too. In singletest.py run everything is OK.
- Changing original STM Cube Driver to call _start instead of main to
initialise the rtos when using it. Without using rtos the behavior is
the same as before.
- Adding DISCO_F429 to rtos
- Adding targets to RTOS_xx tests.
- All tests are OK. Tested with Nucleo and Disco boards. Not tested with
MDOT_F4 but that uses the same hal like nucleo_f411.
sg-
Martin Kojtal
modtronix-com
dbestm
Toyomasa Watarai
tomoyuki yamanaka
neilt6
Dmitry Bogdanov
Olaf Hagendorf
Dmitry Bogdanov
raulMrello
Christoph Plank
Jeremy Brodt
Jun-Ru Chang
Masao Hamanaka
dominus97
Viller Hsiao
Anders Lindvall
nitin.bhaskar.27.09@gmail.com
Adam Green
Per Kristian Gjermshus
GustavWi
Michael Brudevold
Bogdan Marinescu
Takayuki Kurosawa
Lawrence M
Martin Olejar
Mathias Hasselmann
ytsuboi
Martin Kojtal
Bogdan Marinescu
23chrischen
DooWoong Lee