_Swap crash in attempt to add support for STM32F3 board


Mirza Krak
 

Hi.

My first post on this list so would like to say that this project
seems very promising and is something that I have been waiting for.

I wanted to get involved so I dusted of a STM32F3 discovery board and
started coding. It helped a lot that there was STM32F1 support all
ready.

I have gotten it to compile and also have flash and debug support for
the board which has a STlink v2 interface.

But I am having some problems booting the system. As my topic says the
code gets to the _Swap call and then triggers a hard fault.

Do you guys have any tips on why it crashes here?

Posting a gdb trace below:

_nano_fiber_swap () at
/home/mirzak/git/zephyr-project/kernel/nanokernel/nano_fiber.c:159
159 _Swap(imask);
(gdb) s
_Swap () at /home/mirzak/git/zephyr-project/arch/arm/core/swap.S:245
245 ldr r1, =_nanokernel
(gdb) s
246 ldr r2, [r1, #__tNANO_current_OFFSET]
(gdb) s
247 str r0, [r2, #__tTCS_basepri_OFFSET]
(gdb) s
249 svc #0
(gdb) s
__svc () at /home/mirzak/git/zephyr-project/arch/arm/core/swap.S:197
197 eors.n r0, r0
(gdb) s
198 msr BASEPRI, r0
(gdb) s
201 ldr r1, =_SCS_ICSR
(gdb) s
202 ldr r2, =_SCS_ICSR_PENDSV
(gdb) s
203 str r2, [r1, #0]
(gdb) s
208 bx lr
(gdb) s
_Swap () at /home/mirzak/git/zephyr-project/arch/arm/core/swap.S:252
252 bx lr
(gdb) s

^C
Program received signal SIGTRAP, Trace/breakpoint trap.
0x0800130a in _SysFatalErrorHandler (reason=reason(a)entry=0,
pEsf=pEsf(a)entry=0x200004f8 <main_task_stack+944>) at
/home/mirzak/git/zephyr-project/arch/arm/core/sys_fatal_error_handler.c:77
77 if ((curCtx == NANO_CTX_ISR) || _is_thread_essential()) {
(gdb) backtrace
Python Exception <type 'exceptions.ImportError'> No module named gdb.frames:
#0 0x0800130a in _SysFatalErrorHandler (reason=reason(a)entry=0,
pEsf=pEsf(a)entry=0x200004f8 <main_task_stack+944>)
at /home/mirzak/git/zephyr-project/arch/arm/core/sys_fatal_error_handler.c:77
#1 0x080011b8 in _Fault (esf=0x200004f8 <main_task_stack+944>) at
/home/mirzak/git/zephyr-project/arch/arm/core/fault.c:346
#2 0x080012c2 in __usage_fault () at
/home/mirzak/git/zephyr-project/arch/arm/core/fault_s.S:89
#3 <signal handler called>
#4 0x3d45e07c in ?? ()
#5 0xdba824f0 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Best Regards,
Mirza


Benjamin Walsh <benjamin.walsh@...>
 

On Thu, Aug 18, 2016 at 09:43:49PM +0200, Mirza Krak wrote:
Hi.

My first post on this list so would like to say that this project
seems very promising and is something that I have been waiting for.

I wanted to get involved so I dusted of a STM32F3 discovery board and
started coding. It helped a lot that there was STM32F1 support all
ready.

I have gotten it to compile and also have flash and debug support for
the board which has a STlink v2 interface.

But I am having some problems booting the system. As my topic says the
code gets to the _Swap call and then triggers a hard fault.

Do you guys have any tips on why it crashes here?

Posting a gdb trace below:

_nano_fiber_swap () at
/home/mirzak/git/zephyr-project/kernel/nanokernel/nano_fiber.c:159
159 _Swap(imask);
(gdb) s
_Swap () at /home/mirzak/git/zephyr-project/arch/arm/core/swap.S:245
245 ldr r1, =_nanokernel
(gdb) s
246 ldr r2, [r1, #__tNANO_current_OFFSET]
(gdb) s
247 str r0, [r2, #__tTCS_basepri_OFFSET]
(gdb) s
249 svc #0
(gdb) s
__svc () at /home/mirzak/git/zephyr-project/arch/arm/core/swap.S:197
197 eors.n r0, r0
(gdb) s
198 msr BASEPRI, r0
(gdb) s
201 ldr r1, =_SCS_ICSR
(gdb) s
202 ldr r2, =_SCS_ICSR_PENDSV
(gdb) s
203 str r2, [r1, #0]
(gdb) s
208 bx lr
(gdb) s
_Swap () at /home/mirzak/git/zephyr-project/arch/arm/core/swap.S:252
252 bx lr
(gdb) s
Looks like it's going in the weeds when trying to return from the svc
handler. What's the value of the LR register at that time ?


^C
Program received signal SIGTRAP, Trace/breakpoint trap.
0x0800130a in _SysFatalErrorHandler (reason=reason(a)entry=0,
pEsf=pEsf(a)entry=0x200004f8 <main_task_stack+944>) at
/home/mirzak/git/zephyr-project/arch/arm/core/sys_fatal_error_handler.c:77
77 if ((curCtx == NANO_CTX_ISR) || _is_thread_essential()) {
(gdb) backtrace
Python Exception <type 'exceptions.ImportError'> No module named gdb.frames:
#0 0x0800130a in _SysFatalErrorHandler (reason=reason(a)entry=0,
pEsf=pEsf(a)entry=0x200004f8 <main_task_stack+944>)
at /home/mirzak/git/zephyr-project/arch/arm/core/sys_fatal_error_handler.c:77
#1 0x080011b8 in _Fault (esf=0x200004f8 <main_task_stack+944>) at
/home/mirzak/git/zephyr-project/arch/arm/core/fault.c:346
#2 0x080012c2 in __usage_fault () at
/home/mirzak/git/zephyr-project/arch/arm/core/fault_s.S:89
#3 <signal handler called>
#4 0x3d45e07c in ?? ()
#5 0xdba824f0 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Best Regards,
Mirza
--
Benjamin Walsh, SMTS
Wind River Rocket
www.windriver.com
Zephyr kernel maintainer
www.zephyrproject.org


Mirza Krak
 

2016-08-18 21:50 GMT+02:00 Benjamin Walsh <benjamin.walsh(a)windriver.com>:
On Thu, Aug 18, 2016 at 09:43:49PM +0200, Mirza Krak wrote:
Do you guys have any tips on why it crashes here?

Posting a gdb trace below:

_nano_fiber_swap () at
/home/mirzak/git/zephyr-project/kernel/nanokernel/nano_fiber.c:159
159 _Swap(imask);
(gdb) s
_Swap () at /home/mirzak/git/zephyr-project/arch/arm/core/swap.S:245
245 ldr r1, =_nanokernel
(gdb) s
246 ldr r2, [r1, #__tNANO_current_OFFSET]
(gdb) s
247 str r0, [r2, #__tTCS_basepri_OFFSET]
(gdb) s
249 svc #0
(gdb) s
__svc () at /home/mirzak/git/zephyr-project/arch/arm/core/swap.S:197
197 eors.n r0, r0
(gdb) s
198 msr BASEPRI, r0
(gdb) s
201 ldr r1, =_SCS_ICSR
(gdb) s
202 ldr r2, =_SCS_ICSR_PENDSV
(gdb) s
203 str r2, [r1, #0]
(gdb) s
208 bx lr
(gdb) s
_Swap () at /home/mirzak/git/zephyr-project/arch/arm/core/swap.S:252
252 bx lr
(gdb) s
Looks like it's going in the weeds when trying to return from the svc
handler. What's the value of the LR register at that time ?
I get the following just before it tries to exit.

252 bx lr
(gdb) info registers
r0 0x20 32
r1 0x20000120 536871200
r2 0x20009e98 536911512
r3 0x20000044 536870980
r4 0x0 0
r5 0x0 0
r6 0x0 0
r7 0x20009e90 536911504
r8 0x0 0
r9 0x0 0
r10 0x0 0
r11 0x0 0
r12 0x0 0
sp 0x20009e90 0x20009e90
lr 0x8000837 134219831
pc 0x8001020 0x8001020 <_Swap+8>
cpsr 0x21000000 553648128
(gdb) s
^C
Program received signal SIGTRAP, Trace/breakpoint trap.
0x0800130a in _SysFatalErrorHandler (reason=reason(a)entry=0,
pEsf=pEsf(a)entry=0x200004f8 <main_task_stack+944>) at
/home/mirzak/git/zephyr-project/arch/arm/core/sys_fatal_error_handler.c:77
77 if ((curCtx == NANO_CTX_ISR) || _is_thread_essential()) {

Best Regards,
Mirza


Benjamin Walsh <benjamin.walsh@...>
 

On Thu, Aug 18, 2016 at 10:02:07PM +0200, Mirza Krak wrote:
2016-08-18 21:50 GMT+02:00 Benjamin Walsh <benjamin.walsh(a)windriver.com>:
On Thu, Aug 18, 2016 at 09:43:49PM +0200, Mirza Krak wrote:
Do you guys have any tips on why it crashes here?

Posting a gdb trace below:

_nano_fiber_swap () at
/home/mirzak/git/zephyr-project/kernel/nanokernel/nano_fiber.c:159
159 _Swap(imask);
(gdb) s
_Swap () at /home/mirzak/git/zephyr-project/arch/arm/core/swap.S:245
245 ldr r1, =_nanokernel
(gdb) s
246 ldr r2, [r1, #__tNANO_current_OFFSET]
(gdb) s
247 str r0, [r2, #__tTCS_basepri_OFFSET]
(gdb) s
249 svc #0
(gdb) s
__svc () at /home/mirzak/git/zephyr-project/arch/arm/core/swap.S:197
197 eors.n r0, r0
(gdb) s
198 msr BASEPRI, r0
(gdb) s
201 ldr r1, =_SCS_ICSR
(gdb) s
202 ldr r2, =_SCS_ICSR_PENDSV
(gdb) s
203 str r2, [r1, #0]
(gdb) s
208 bx lr
(gdb) s
_Swap () at /home/mirzak/git/zephyr-project/arch/arm/core/swap.S:252
252 bx lr
(gdb) s
Looks like it's going in the weeds when trying to return from the svc
handler. What's the value of the LR register at that time ?
I get the following just before it tries to exit.

252 bx lr
(gdb) info registers
r0 0x20 32
r1 0x20000120 536871200
r2 0x20009e98 536911512
r3 0x20000044 536870980
r4 0x0 0
r5 0x0 0
r6 0x0 0
r7 0x20009e90 536911504
r8 0x0 0
r9 0x0 0
r10 0x0 0
r11 0x0 0
r12 0x0 0
sp 0x20009e90 0x20009e90
lr 0x8000837 134219831
^^^^^^^^^

Contents of lr looks corrupted: it should be something like 0xfffffffd.
Is it OK when entering __svc() ?

Are you trying to run a stock project or is it your own application ?

pc 0x8001020 0x8001020 <_Swap+8>
cpsr 0x21000000 553648128
(gdb) s
^C
Program received signal SIGTRAP, Trace/breakpoint trap.
0x0800130a in _SysFatalErrorHandler (reason=reason(a)entry=0,
pEsf=pEsf(a)entry=0x200004f8 <main_task_stack+944>) at
/home/mirzak/git/zephyr-project/arch/arm/core/sys_fatal_error_handler.c:77
77 if ((curCtx == NANO_CTX_ISR) || _is_thread_essential()) {

Best Regards,
Mirza


Mirza Krak
 

2016-08-18 22:55 GMT+02:00 Benjamin Walsh <benjamin.walsh(a)windriver.com>:
On Thu, Aug 18, 2016 at 10:02:07PM +0200, Mirza Krak wrote:
2016-08-18 21:50 GMT+02:00 Benjamin Walsh <benjamin.walsh(a)windriver.com>:
On Thu, Aug 18, 2016 at 09:43:49PM +0200, Mirza Krak wrote:
Do you guys have any tips on why it crashes here?
sp 0x20009e90 0x20009e90
lr 0x8000837 134219831
^^^^^^^^^

Contents of lr looks corrupted: it should be something like 0xfffffffd.
Is it OK when entering __svc() ?
It seems to be corrupted when entering __svc, but once inside the
__svc it seems to have a value of what you where expecting.

(gdb) s
249 svc #0
(gdb) info registers
r0 0x20 32
r1 0x20000138 536871224
r2 0x20009e98 536911512
r3 0x20000060 536871008
r4 0x0 0
r5 0x0 0
r6 0x0 0
r7 0x20009e90 536911504
r8 0x0 0
r9 0x0 0
r10 0x0 0
r11 0x0 0
r12 0x0 0
sp 0x20009e90 0x20009e90
lr 0x8000a6f 134220399
pc 0x8001256 0x8001256 <_Swap+6>
cpsr 0x21000000 553648128
(gdb) s
__svc () at /home/mirzak/git/zephyr-project/arch/arm/core/swap.S:197
197 eors.n r0, r0
(gdb) info registers
r0 0x20 32
r1 0x20000138 536871224
r2 0x20009e98 536911512
r3 0x20000060 536871008
r4 0x0 0
r5 0x0 0
r6 0x0 0
r7 0x20009e90 536911504
r8 0x0 0
r9 0x0 0
r10 0x0 0
r11 0x0 0
r12 0x0 0
sp 0x20000d60 0x20000d60
lr 0xfffffffd 4294967293
pc 0x8001238 0x8001238 <__svc>
cpsr 0x2100000b 553648139>

Are you trying to run a stock project or is it your own application ?
I am attempting to run the samples/drivers/gpio application.

Best Regards
Mirza


Mirza Krak
 

2016-08-18 22:55 GMT+02:00 Benjamin Walsh <benjamin.walsh(a)windriver.com>:
On Thu, Aug 18, 2016 at 10:02:07PM +0200, Mirza Krak wrote:
2016-08-18 21:50 GMT+02:00 Benjamin Walsh <benjamin.walsh(a)windriver.com>:
On Thu, Aug 18, 2016 at 09:43:49PM +0200, Mirza Krak wrote:
Do you guys have any tips on why it crashes here?
sp 0x20009e90 0x20009e90
lr 0x8000837 134219831
^^^^^^^^^

Contents of lr looks corrupted: it should be something like 0xfffffffd.
Is it OK when entering __svc() ?
But if I understand this correctly, shouldn't LR contain the address
of main at this stage.

The code says:
/* context switch to main task (entry function is _main()) */
_nano_fiber_swap();

I am not sure where it does get the address of main though. Because I
cant find the address that LR has when entering __Swap in any of of
the files (.map .lst), and maybe that is the root of it.

Best Regards
Mirza


Benjamin Walsh <benjamin.walsh@...>
 

On Thu, Aug 18, 2016 at 11:07:32PM +0200, Mirza Krak wrote:
2016-08-18 22:55 GMT+02:00 Benjamin Walsh <benjamin.walsh(a)windriver.com>:
On Thu, Aug 18, 2016 at 10:02:07PM +0200, Mirza Krak wrote:
2016-08-18 21:50 GMT+02:00 Benjamin Walsh <benjamin.walsh(a)windriver.com>:
On Thu, Aug 18, 2016 at 09:43:49PM +0200, Mirza Krak wrote:
Do you guys have any tips on why it crashes here?
sp 0x20009e90 0x20009e90
lr 0x8000837 134219831
^^^^^^^^^

Contents of lr looks corrupted: it should be something like 0xfffffffd.
Is it OK when entering __svc() ?
It seems to be corrupted when entering __svc, but once inside the
__svc it seems to have a value of what you where expecting.
Ah, no, this might be OK then. 0xfffffffd gets put by the CPU when
taking the SVC exception and entering __svc().

If this is the very first call to _Swap() when the kernel boots, that
call will never return.


(gdb) s
249 svc #0
(gdb) info registers
r0 0x20 32
r1 0x20000138 536871224
r2 0x20009e98 536911512
r3 0x20000060 536871008
r4 0x0 0
r5 0x0 0
r6 0x0 0
r7 0x20009e90 536911504
r8 0x0 0
r9 0x0 0
r10 0x0 0
r11 0x0 0
r12 0x0 0
sp 0x20009e90 0x20009e90
lr 0x8000a6f 134220399
pc 0x8001256 0x8001256 <_Swap+6>
^^^^^^^^^
Although, these addresses look weird: normally the .text section is at 0
on these targets, but the PC shows an address in the 0x8001256 range as
well, and it is resolved as being _Swap+6. I suppose the link address is
different on that board.

cpsr 0x21000000 553648128
(gdb) s
__svc () at /home/mirzak/git/zephyr-project/arch/arm/core/swap.S:197
197 eors.n r0, r0
(gdb) info registers
r0 0x20 32
r1 0x20000138 536871224
r2 0x20009e98 536911512
r3 0x20000060 536871008
r4 0x0 0
r5 0x0 0
r6 0x0 0
r7 0x20009e90 536911504
r8 0x0 0
r9 0x0 0
r10 0x0 0
r11 0x0 0
r12 0x0 0
sp 0x20000d60 0x20000d60
lr 0xfffffffd 4294967293
pc 0x8001238 0x8001238 <__svc>
cpsr 0x2100000b 553648139>

Are you trying to run a stock project or is it your own application ?
I am attempting to run the samples/drivers/gpio application.
The comments in main.c list a bunch of boards, but not the STM ones.

I guess you adapted it to run on your board ?

Cheers,
Ben


Benjamin Walsh <benjamin.walsh@...>
 

On Thu, Aug 18, 2016 at 11:23:15PM +0200, Mirza Krak wrote:
2016-08-18 22:55 GMT+02:00 Benjamin Walsh <benjamin.walsh(a)windriver.com>:
On Thu, Aug 18, 2016 at 10:02:07PM +0200, Mirza Krak wrote:
2016-08-18 21:50 GMT+02:00 Benjamin Walsh <benjamin.walsh(a)windriver.com>:
On Thu, Aug 18, 2016 at 09:43:49PM +0200, Mirza Krak wrote:
Do you guys have any tips on why it crashes here?
sp 0x20009e90 0x20009e90
lr 0x8000837 134219831
^^^^^^^^^

Contents of lr looks corrupted: it should be something like 0xfffffffd.
Is it OK when entering __svc() ?
But if I understand this correctly, shouldn't LR contain the address
of main at this stage.
Not at this point. The address of main() will be loaded from the stack
of the main thread when the CPU returns from the PendSV exception and
the main thread is the next one to run. Actually it will be the address
of a wrapper around the thread, and will be loaded into the PC
register, not LR.

The code says:
/* context switch to main task (entry function is _main()) */
_nano_fiber_swap();

I am not sure where it does get the address of main though. Because I
cant find the address that LR has when entering __Swap in any of of
the files (.map .lst), and maybe that is the root of it.
The address in LR when entering _Swap() is the one of the next
instruction after the branch to _Swap(). It's probably in the middle of
a function.


Ricardo Salveti <ricardo.salveti@...>
 

On Thu, Aug 18, 2016 at 4:43 PM, Mirza Krak <mirza.krak(a)gmail.com> wrote:
Hi.

My first post on this list so would like to say that this project
seems very promising and is something that I have been waiting for.

I wanted to get involved so I dusted of a STM32F3 discovery board and
started coding. It helped a lot that there was STM32F1 support all
ready.
Not related to your issue, but we also got a work-in-progress port for
STM32F4 last week, in case that is useful for you. Currently working
at https://github.com/rsalveti/zephyr/commits/stm32-dev, and expecting
to start the clean-up and upstreaming over the next couple of weeks.

Clock, uart, gpio, all working and tested with STM32F4 Nucleo.

Cheers,
--
Ricardo Salveti


Mirza Krak
 

2016-08-19 4:25 GMT+02:00 Ricardo Salveti <ricardo.salveti(a)linaro.org>:
On Thu, Aug 18, 2016 at 4:43 PM, Mirza Krak <mirza.krak(a)gmail.com> wrote:
Hi.

My first post on this list so would like to say that this project
seems very promising and is something that I have been waiting for.

I wanted to get involved so I dusted of a STM32F3 discovery board and
started coding. It helped a lot that there was STM32F1 support all
ready.
Not related to your issue, but we also got a work-in-progress port for
STM32F4 last week, in case that is useful for you. Currently working
at https://github.com/rsalveti/zephyr/commits/stm32-dev, and expecting
to start the clean-up and upstreaming over the next couple of weeks.

Clock, uart, gpio, all working and tested with STM32F4 Nucleo.
Interesting. Will take a look at your project. An STM32F4 should be
more similar to the F3 then mainstream F1 support, which should make
my port easier.

Best Regards
Mirza


Mirza Krak
 

2016-08-19 4:25 GMT+02:00 Ricardo Salveti <ricardo.salveti(a)linaro.org>:
On Thu, Aug 18, 2016 at 4:43 PM, Mirza Krak <mirza.krak(a)gmail.com> wrote:
Hi.

My first post on this list so would like to say that this project
seems very promising and is something that I have been waiting for.

I wanted to get involved so I dusted of a STM32F3 discovery board and
started coding. It helped a lot that there was STM32F1 support all
ready.
Not related to your issue, but we also got a work-in-progress port for
STM32F4 last week, in case that is useful for you. Currently working
at https://github.com/rsalveti/zephyr/commits/stm32-dev, and expecting
to start the clean-up and upstreaming over the next couple of weeks.

Clock, uart, gpio, all working and tested with STM32F4 Nucleo.
Thank you for sharing your port, it was really helpful and my work is
heavily based on that.

FYI I now also have a STM32F3 Discovery board working (only clock and
gpio so far). Will also implement GPIO IRQ support. But then I plan to
start cleaning up and attempt to mainline. Will do the uart part later
since it is significantly different compared to F1 and F4.

I am not sure about your timeline, but we could end up clashing with
our ports. So I am unsure how it is best to proceed forward in
attempting to mainline.

I will happily move forward in a join effort.

My port is available on https://github.com/mirzak/zephyr-os/tree/stm32f3

Best Regards,
Mirza Krak


Amit Kucheria
 

On Mon, Aug 22, 2016 at 8:16 PM, Mirza Krak <mirza.krak(a)gmail.com> wrote:
2016-08-19 4:25 GMT+02:00 Ricardo Salveti <ricardo.salveti(a)linaro.org>:
On Thu, Aug 18, 2016 at 4:43 PM, Mirza Krak <mirza.krak(a)gmail.com> wrote:
Hi.

My first post on this list so would like to say that this project
seems very promising and is something that I have been waiting for.

I wanted to get involved so I dusted of a STM32F3 discovery board and
started coding. It helped a lot that there was STM32F1 support all
ready.
Not related to your issue, but we also got a work-in-progress port for
STM32F4 last week, in case that is useful for you. Currently working
at https://github.com/rsalveti/zephyr/commits/stm32-dev, and expecting
to start the clean-up and upstreaming over the next couple of weeks.

Clock, uart, gpio, all working and tested with STM32F4 Nucleo.
Thank you for sharing your port, it was really helpful and my work is
heavily based on that.

FYI I now also have a STM32F3 Discovery board working (only clock and
gpio so far). Will also implement GPIO IRQ support. But then I plan to
start cleaning up and attempt to mainline. Will do the uart part later
since it is significantly different compared to F1 and F4.

I am not sure about your timeline, but we could end up clashing with
our ports. So I am unsure how it is best to proceed forward in
attempting to mainline.

I will happily move forward in a join effort.

My port is available on https://github.com/mirzak/zephyr-os/tree/stm32f3
Mirza,

I expect we'll start cleaning up our port in a week or two. I'm trying
to finish up the SPI driver before starting a cleanup.

Cheers,
Amit


Mirza Krak
 

2016-08-22 18:38 GMT+02:00 Amit Kucheria <amit.kucheria(a)verdurent.com>:

Mirza,

I expect we'll start cleaning up our port in a week or two. I'm trying
to finish up the SPI driver before starting a cleanup.
Hi Amit.

Good to know that you are working on a SPI driver, I was planing on
doing that as well. Now I wont :).

I will wait for your clean-up then, I will be going on vacation next
week and I am probably not gonna finish anything until then.

Best Regards
Mirza


Maciek Borzecki <maciek.borzecki@...>
 

On Mon, Aug 22, 2016 at 4:46 PM, Mirza Krak <mirza.krak(a)gmail.com> wrote:
2016-08-19 4:25 GMT+02:00 Ricardo Salveti <ricardo.salveti(a)linaro.org>:
On Thu, Aug 18, 2016 at 4:43 PM, Mirza Krak <mirza.krak(a)gmail.com> wrote:
Hi.

My first post on this list so would like to say that this project
seems very promising and is something that I have been waiting for.

I wanted to get involved so I dusted of a STM32F3 discovery board and
started coding. It helped a lot that there was STM32F1 support all
ready.
Not related to your issue, but we also got a work-in-progress port for
STM32F4 last week, in case that is useful for you. Currently working
at https://github.com/rsalveti/zephyr/commits/stm32-dev, and expecting
to start the clean-up and upstreaming over the next couple of weeks.

Clock, uart, gpio, all working and tested with STM32F4 Nucleo.
Thank you for sharing your port, it was really helpful and my work is
heavily based on that.

FYI I now also have a STM32F3 Discovery board working (only clock and
gpio so far). Will also implement GPIO IRQ support. But then I plan to
start cleaning up and attempt to mainline. Will do the uart part later
since it is significantly different compared to F1 and F4.

I am not sure about your timeline, but we could end up clashing with
our ports. So I am unsure how it is best to proceed forward in
attempting to mainline.

I will happily move forward in a join effort.

My port is available on https://github.com/mirzak/zephyr-os/tree/stm32f3
Author of SM32F1 port here. I started working on STM32F3 back in March
and most of the changes I did at that time were pushed here:
https://github.com/bboozzoo/zephyr/commits/bboozzoo/stm32f3
The idea was to extract common pieces of STM32 functionality and have
individual STM32[FL]x ports provide chip specific overrides. That was
before external libraries were introduced, so I guess I would
reevaluate the approach if I were to start now.

Anyways, since then I have moved to other projects. However guys from
my team used the that tree as a base for their F3/F4 ports that AFAIK
are currently being shipped as part of a commercial project for one of
our customers (along with drivers for DAC and some sensors). Also, the
port was supposed to be posted for upstream review at some point.

I believe they should be subscribed to devel, but I will ping them to
check their status once I get back from vacation next week.

Cheers,
--
Maciek Borzecki