cpu/stm32: add support for U5 family#17410
Conversation
aabadie
added
the
Type: new feature
aabadie
requested review from
DipSwitch,
cgundogan,
fjmolinas,
jia200x,
kaspar030,
leandrolanzieri and
vincent-d
as code owners
github-actions
bot
added
Area: boards
aabadie
force-pushed
the
pr/cpu/stm32u5
branch
from
bf58719 to
6bfdcd5
Compare
aabadie
force-pushed
the
pr/cpu/stm32u5
branch
from
6bfdcd5 to
6723de4
Compare
benpicco
added
the
CI: ready for build
|
Code looks good! |
I just keep the end (and after increasing the test timeout to 30s): GDB doesn't give much information. I tried to change the RAM_LEN to something smaller (that corresponds to SRAM1/2/3 or just SRAM1) but it crashes the same. I don't understand the problem. For the record, here are the outputs of the other failing tests: tests/malloc_thread_safetytests/pthread_rwlocktests/sys_sema_inv |
|
"SRAM1/2/3 Non-secure" only goes to
You can define multiple heap regions in the linker script (e.g. see |
Yes, I saw that gap, that's why I only set RAM_LEN to be SRAM1 + 2 + 3 (768K) but it still crashes. Even with super small values of RAM_LEN (like 64K). |
|
Just tried the first I2C configured with a MEMs shield, it works: |
huh that's strange - what address is it crashing on then? |
When I set 64K, it's crashing at Maybe there's a reserved space ? I couldn't find any information about that. |
aabadie
force-pushed
the
pr/cpu/stm32u5
branch
from
37856d5 to
6f8ce8a
Compare
aabadie
force-pushed
the
pr/cpu/stm32u5
branch
from
4057a2f to
7e3256a
Compare
aabadie
force-pushed
the
pr/cpu/stm32u5
branch
2 times, most recently
from
2c628b2 to
b5509b2
Compare
cpu/stm32/Makefile.include
Outdated
| ifeq (u5,$(CPU_FAM)) | ||
| LINKER_SCRIPT ?= stm32u5.ld | ||
| else | ||
| LINKER_SCRIPT ?= stm32.ld |
There was a problem hiding this comment.
Oh I didn't realize we already have a custom linker script for stm32 - then let's use this instead
diff --git a/cpu/stm32/Makefile.include b/cpu/stm32/Makefile.include
index 884890ccc1..406f58a34c 100644
--- a/cpu/stm32/Makefile.include
+++ b/cpu/stm32/Makefile.include
@@ -61,6 +61,9 @@ info-stm32:
ifneq (,$(CCMRAM_LEN))
LINKFLAGS += $(LINKFLAGPREFIX)--defsym=_ccmram_length=$(CCMRAM_LEN)
endif
+ifneq (,$(SRAM4_LEN))
+ LINKFLAGS += $(LINKFLAGPREFIX)--defsym=_sram4_length=$(SRAM4_LEN)
+endif
VECTORS_O ?= $(BINDIR)/stm32_vectors/$(CPU_LINE).o
VECTORS_FILE = $(RIOTCPU)/stm32/vectors/$(CPU_LINE).c
diff --git a/cpu/stm32/ldscripts/stm32.ld b/cpu/stm32/ldscripts/stm32.ld
index fb50fcf119..3e429d879d 100644
--- a/cpu/stm32/ldscripts/stm32.ld
+++ b/cpu/stm32/ldscripts/stm32.ld
@@ -19,10 +19,12 @@
*/
ccmram_length = DEFINED( ccmram_len ) ? ccmram_len : 0x0 ;
+sram4_length = DEFINED( sram4_length ) ? sram4_length : 0x0 ;
MEMORY
{
ccmram : ORIGIN = 0x10000000, LENGTH = ccmram_length
+ sram4 : ORIGIN = 0x28000000, LENGTH = sram4_length
}
INCLUDE cortexm.ldThere was a problem hiding this comment.
Ah but why remove
#define NUM_HEAPS 2from cpu_conf.h ?
There was a problem hiding this comment.
I don't really know why it's required, I thought it was useless.
There was a problem hiding this comment.
It's used by syscalls.c to provide non-continuous memory sections as additional heap used by malloc
|
nRF9160 seems not affect by your issue. |
Are you using ARM GCC 10 ? |
Yes, my local version is |
aabadie
force-pushed
the
pr/cpu/stm32u5
branch
2 times, most recently
from
c4309c1 to
2290601
Compare
aabadie
force-pushed
the
pr/cpu/stm32u5
branch
from
2290601 to
d5be810
Compare
|
Oh but but So for now we can change SRAM4 to |
aabadie
force-pushed
the
pr/cpu/stm32u5
branch
from
d5be810 to
8607a9c
Compare
I think I've done that but not sure. |
|
Thanks @benpicco for reviewing and merging ! |
19817: compile_and_test_for_boards: Add no-compile flag r=benpicco a=MrKevinWeiss ### Contribution description Since we have a no-test flag that prevents executing tests, I think a no-compile flag is a nice compliment. Why? Well if I want to use this script for running multiple boards at the same time, RIOT is not so great handling parallel compile steps with conflicts on lockfiles happening, mostly due to packages. With this I can compile a list of boards sequentially, then flash and run tests in parallel, skipping the compile step. ### Testing procedure Run the following once to compile and clean: ``` ./dist/tools/compile_and_test_for_board/compile_and_test_for_board.py . native --applications tests/sys/shell --clean-after ``` Then try to run without the compile step and it should fail due to lack of the binary ``` ./dist/tools/compile_and_test_for_board/compile_and_test_for_board.py . native --applications tests/sys/shell --no-compile ``` ### Issues/PRs references 19826: ztimer/periodic: reinit remove from right clock and handle aquired ztimer r=benpicco a=kfessel ### Contribution description #19806 added some retinit handling for ztimer periodic removing the timer from the new clock This tries to detect if this is a reinit and remove the timer from the old clock this also removes the ztimer_acquire/_release handling by removing now calls in favour of set return value and now values that are allready in ztimer, that also has the potential to reduce the jitter of the periodic calls and bus-usage (for cpus that take their time to get "now") ### Testing procedure read run tests/sys/ztimer_periodic ### Issues/PRs references Fixes #19806 19841: boards/adafruit-itsybitsy-nrf52: Add configuration for DotStar LED r=benpicco a=jimporter 19842: cpu/stm32: fix ld script for SRAM4 r=benpicco a=gschorcht ### Contribution description This PR fixes the LD script for STM32. Since the CCM and SRAM4 length are defined as symbols with perifx `_`, the LD script didn't use them correctly. Instead of using `ccmram_length` and `sram4_length`, `_ccmram_length` and `_sram4_length` have to be used. Furthermore, the location counter for the SRAM has to be set to the beginning of SRAM4 to work. BTW, I don't understand why the `ccmram` region is defined. There is no section definition that would use it to place code or data with attribute `.ccmram.*` there. Without the fix in this PR, defined symbols in `tests/sys/malloc` for the `b-u585i-iot02a` board were: ```python 00000000 T _sheap2 <== wrong start position because of wrong location counter 28000000 T _eheap2 <== wrong end position because of `sram4_length` is 0. ``` Although the `tests/sys/malloc` crashes for `b-u585i-iot02a` at the end of the heap (known problem, see [here](#17410 (comment))), it uses only the backup RAM before it crashes: ``` Allocated 512 Bytes at 0x200bf600, total 756072 Allocated 512 Bytes at 0x200bf818, total 756592 Allocated 512 Bytes at 0x200bfa30, total 757112 Allocated 512 Bytes at 0x200bfc48, total 757632 Allocated 512 Bytes at 0x40036408, total 758152 Allocated 512 Bytes at 0x40036610, total 758672 Allocated 512 Bytes at 0x40036818, total 759192 ``` With the fix in this PR, defined symbols in `tests/sys/malloc` for the `b-u585i-iot02a` board are: ```python 28000000 T _sheap2 <== correct start position 28004000 T _eheap2 <== correct end position ``` `tests/sys/malloc` also crashes for the `b-u585i-iot02a` at the end of the heap, but it uses also the SRAM4 before it crashes. ``` Allocated 512 Bytes at 0x200bf600, total 756072 Allocated 512 Bytes at 0x200bf818, total 756592 Allocated 512 Bytes at 0x200bfa30, total 757112 Allocated 512 Bytes at 0x200bfc48, total 757632 Allocated 512 Bytes at 0x40036408, total 758152 Allocated 512 Bytes at 0x40036610, total 758672 Allocated 512 Bytes at 0x40036818, total 759192 Allocated 512 Bytes at 0x28000008, total 759712 Allocated 512 Bytes at 0x28000210, total 760232 Allocated 512 Bytes at 0x28000418, total 760752 ... Allocated 512 Bytes at 0x280038e8, total 774272 Allocated 512 Bytes at 0x28003af0, total 774792 Allocated 512 Bytes at 0x28003cf8, total 775312 ``` ### Testing procedure 1. Flash `tests/sys/malloc` and use `MAX_MEM` limit to stop `malloc` before the crash: ``` CFLAGS='-DMAX_MEM=774800 -DCHUNK_SIZE=512 -DDEBUG_ASSERT_VERBOSE' \ BOARD=b-u585i-iot02a make -j8 -C tests/sys/malloc flash ``` Without the PR it crashes at the end of the backup RAM. With the PR it works. 2. Check `_sheap2` and `_eheap2` with ``` nm -s tests/sys/malloc/bin/b-u585i-iot02a/tests_malloc.elf | grep heap2 | sort ``` Without the PR it will be: ``` 00000000 T _sheap2 28000000 T _eheap2 ``` With the PR it should be: ``` 28000000 T _sheap2 28004000 T _eheap2 ``` ### Issues/PRs references Co-authored-by: MrKevinWeiss <weiss.kevin604@gmail.com> Co-authored-by: Karl Fessel <karl.fessel@ovgu.de> Co-authored-by: Jim Porter <jporterbugs@gmail.com> Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
I tried to figure out what the problem is. The hard fault happens here (debugger output) r0 0xffffffff -1 r1 0x200c0198 537657752
r2 0xc 12 r3 0x0 0
r4 0x0 0 r5 0x408 1032
r6 0x0 0 r7 0x20000220 536871456
xpsr 0x61000000 1627389952 fpscr 0x0 0
msp 0x200001c8 0x200001c8 psp 0x20000800 0x20000800
...
0x80016d8 <_malloc_r+56> bl 0x8001660 <sbrk_aligned>
0x80016dc <_malloc_r+60> adds r3, r0, #1
0x80016de <_malloc_r+62> mov r4, r0
0x80016e0 <_malloc_r+64> bne.n 0x800177e <_malloc_r+222>
0x80016e2 <_malloc_r+66> ldr r4, [r6, #0]
0x80016e4 <_malloc_r+68> mov r6, r4
0x80016e6 <_malloc_r+70> cmp r6, #0
0x80016e8 <_malloc_r+72> bne.n 0x800176c <_malloc_r+204>
> 0x80016ea <_malloc_r+74> ldr r3, [r4, #0]after calling The return value from However, if To be honest, I'm a bit confused by the code. If I'm right, I think the corresponding source code can be found here in lines 308-324. The crash happens on dreferencing 308 r = sbrk_aligned(RCALL alloc_size);
309
310 /* sbrk returns -1 if fail to allocate */
311 if (r == (void *)-1)
312 {
313 /* sbrk didn't have the requested amount. Let's check
314 * if the last item in the free list is adjacent to the
315 * current heap end (sbrk(0)). In that case, only ask
316 * for the difference in size and merge them */
317 p = free_list;
318 r = p;
319
320 while (r)
321 {
322 p=r;
323 r=r->next;
324 }So the question is how can the processor enter the while loop if |
|
BTW, it seems to work with the gcc 12.2 toolchain. |
|
It does indeed seem to be a bug in the 8001f4a: f7ff ffbf bl 8001ecc <sbrk_aligned>
8001f4e: 1c43 adds r3, r0, #1
8001f50: 4604 mov r4, r0
8001f52: d158 bne.n 8002006 <_malloc_r+0xf6>
8001f54: f8d8 4000 ldr.w r4, [r8]
8001f58: 4627 mov r7, r4
8001f5a: 2f00 cmp r7, #0
8001f5c: d143 bne.n 8001fe6 <_malloc_r+0xd6>
-> 8001f5e: 2c00 cmp r4, #0
-> 8001f60: d04b beq.n 8001ffa <_malloc_r+0xea>
8001f62: 6823 ldr r3, [r4, #0]It now tests |
|
This was obviously the fix and the description |
|
So we can't do anything from our side other than to upgrade to the |
|
Fortunately that's also what Ubuntu ships these days
We'll just have to update riotdocker |
5 participants
Contribution description
This PR adds support for the new STM32 U5 series and adds support for the B-U585i-IOT02A development kit board.
The U5 is am M33, similar to the L5 but with more RAM/Flash. As usual, there are quite some differences, especially with the clock management (2 MSIs, registers to configure the PLL are different, etc).
The port is very basic: only GPIO, UART, Flashpage and Timer peripherals are tested. There's also a configuration for I2C (that should work) but is not tested yet.
SPI registers have changed names so the driver needs to be adapted.
There's no clock configuration via Kconfig available. I don't know if that's mandatory or not.
Testing procedure
compile_and_test_for_board.py:Some failures are related to RAM. I don't know yet what's the problem with
tests/pkg_cifra.Issues/PRs references
None