STM32F107 on STM3210C-EVAL

STM32F107 on STM3210C-EVAL

[Gian Maria]

I'm porting eCos to STM3210C and I find a logical error on the
implementation of CYGPKG_HAL_CORTEXM_STM32.
CYGPKG_HAL_CORTEXM_STM32 must be the base of all STM32 uP and so is not
correct for me to use

    cdl_option CYGHWR_HAL_CORTEXM_STM32 {
        display          "STM32 variant in use"
        flavor           data
        default_value    {"F103ZE"}
        legal_values     {"F103RC" "F103VC" "F103ZC"
                          "F103RD" "F103VD" "F103ZD"
                          "F103RE" "F103VE" "F103ZE" }
        description      "The STM32 has several variants, the main
differences
                          being in the size of on-chip FLASH and SRAM
                          and numbers of some peripherals. This option
                          allows the platform HAL to select the specific
                          microcontroller fitted."
    }

That is inside "ecoscvs\ecos\packages\hal\cortexm\stm32\var\current\cdl",
because with my EVB for example 
the uP is a STM32F107VC. With this I can't set the right uP as default for
the template.
I'm right? I think the correct is to put the code inside
"ecoscvs\ecos\packages\hal\cortexm\stm32\stm3210e_eval\current\cdl"

Can someone modify this so I can update my CVS and work with the right code?

Best regards Gisn.

PS: 
1 - When I finish my piece of port, that is at the beginning and I'm
learning eCos who can upload?
2 - For every suggest Is this the right place?
3 - I have to post the full port or can post pieces of code as they are
ready?

Re: STM32F107 on STM3210C-EVAL

[John Dallaway]

Hi Gian Maria

Gian Maria wrote:

> I'm porting eCos to STM3210C and I find a logical error on the
> implementation of CYGPKG_HAL_CORTEXM_STM32.
> CYGPKG_HAL_CORTEXM_STM32 must be the base of all STM32 uP and so is not
> correct for me to use
> 
>     cdl_option CYGHWR_HAL_CORTEXM_STM32 {
>         display          "STM32 variant in use"
>         flavor           data
>         default_value    {"F103ZE"}
>         legal_values     {"F103RC" "F103VC" "F103ZC"
>                           "F103RD" "F103VD" "F103ZD"
>                           "F103RE" "F103VE" "F103ZE" }
>         description      "The STM32 has several variants, the main differences
>                           being in the size of on-chip FLASH and SRAM
>                           and numbers of some peripherals. This option
>                           allows the platform HAL to select the specific
>                           microcontroller fitted."
>     }
> 
> That is inside "ecoscvs\ecos\packages\hal\cortexm\stm32\var\current\cdl",
> because with my EVB for example 
> the uP is a STM32F107VC. With this I can't set the right uP as default for
> the template.
> I'm right? I think the correct is to put the code inside
> "ecoscvs\ecos\packages\hal\cortexm\stm32\stm3210e_eval\current\cdl"

I am not sure I understand your question. Are you intending to create a
new platform HAL package for STM3210C-EVAL?

> Can someone modify this so I can update my CVS and work with the right code?

It will be no problem to extend the set of legal values for
CYGHWR_HAL_CORTEXM_STM32. Of course, you can make this change in your
local CVS checkout until you are ready to contribute your platform
support for STM3210C-EVAL.

> 1 - When I finish my piece of port, that is at the beginning and I'm
> learning eCos who can upload?

Please refer to the eCos contributions page for details of the
contribution procedure:

  http://ecos.sourceware.org/contrib.html

> 2 - For every suggest Is this the right place?

Yes, ecos-devel is a good place to discuss platform porting strategy.

> 3 - I have to post the full port or can post pieces of code as they are
> ready?

It is a good idea to develop in the open so that other people can advise
you on best practice. However, the maintainers will wait until you make
a full formal contribution (via Bugzilla) before review. You will also
need to make a copyright assignment. Ref:

  http://ecos.sourceware.org/assign.html

John Dallaway
eCos maintainer
http://www.dallaway.org.uk/john

Re: STM32F107 on STM3210C-EVAL

[Ilija Kocho]

On 23.03.2011 11:50, John Dallaway wrote:
> Hi Gian Maria
>
> Gian Maria wrote:
>
>> I'm porting eCos to STM3210C and I find a logical error on the
>> implementation of CYGPKG_HAL_CORTEXM_STM32.
>> CYGPKG_HAL_CORTEXM_STM32 must be the base of all STM32 uP and so is not
>> correct for me to use
>>
>>     cdl_option CYGHWR_HAL_CORTEXM_STM32 {
>>         display          "STM32 variant in use"
>>         flavor           data
>>         default_value    {"F103ZE"}
>>         legal_values     {"F103RC" "F103VC" "F103ZC"
>>                           "F103RD" "F103VD" "F103ZD"
>>                           "F103RE" "F103VE" "F103ZE" }
>>         description      "The STM32 has several variants, the main differences
>>                           being in the size of on-chip FLASH and SRAM
>>                           and numbers of some peripherals. This option
>>                           allows the platform HAL to select the specific
>>                           microcontroller fitted."
>>     }
>>
>> That is inside "ecoscvs\ecos\packages\hal\cortexm\stm32\var\current\cdl",
>> because with my EVB for example 
>> the uP is a STM32F107VC. With this I can't set the right uP as default for
>> the template.
>> I'm right? I think the correct is to put the code inside
>> "ecoscvs\ecos\packages\hal\cortexm\stm32\stm3210e_eval\current\cdl"
> I am not sure I understand your question. Are you intending to create a
> new platform HAL package for STM3210C-EVAL?
>
>> Can someone modify this so I can update my CVS and work with the right code?
> It will be no problem to extend the set of legal values for
> CYGHWR_HAL_CORTEXM_STM32. Of course, you can make this change in your
> local CVS checkout until you are ready to contribute your platform
> support for STM3210C-EVAL.

Current STM32 code, as is, would not work for single chip configuration
as it unconditionally depends on external RAM. In SIvA we have an
internal modification that enables single chip operation and if there is
an interest we would post a patch.

Note: Our code is tested on ST STM3210E EVAL, i.e. not tested with
Connectivity line member.

Regards
Ilija

RE: Re: STM32F107 on STM3210C-EVAL

[qber_]

Hi

W dniu 2011-03-26 12:07:30 użytkownik Ilija Kocho <ilijak@siva.com.mk> napisał:
> On 23.03.2011 11:50, John Dallaway wrote:
> > Hi Gian Maria
> >
> > Gian Maria wrote:
> >
> >> I'm porting eCos to STM3210C and I find a logical error on the
> >> implementation of CYGPKG_HAL_CORTEXM_STM32.
> >> CYGPKG_HAL_CORTEXM_STM32 must be the base of all STM32 uP and so is not
> >> correct for me to use
> >>
> >>     cdl_option CYGHWR_HAL_CORTEXM_STM32 {
> >>         display          "STM32 variant in use"
> >>         flavor           data
> >>         default_value    {"F103ZE"}
> >>         legal_values     {"F103RC" "F103VC" "F103ZC"
> >>                           "F103RD" "F103VD" "F103ZD"
> >>                           "F103RE" "F103VE" "F103ZE" }
> >>         description      "The STM32 has several variants, the main differences
> >>                           being in the size of on-chip FLASH and SRAM
> >>                           and numbers of some peripherals. This option
> >>                           allows the platform HAL to select the specific
> >>                           microcontroller fitted."
> >>     }
> >>
> >> That is inside "ecoscvs\ecos\packages\hal\cortexm\stm32\var\current\cdl",
> >> because with my EVB for example 
> >> the uP is a STM32F107VC. With this I can't set the right uP as default for
> >> the template.
> >> I'm right? I think the correct is to put the code inside
> >> "ecoscvs\ecos\packages\hal\cortexm\stm32\stm3210e_eval\current\cdl"
> > I am not sure I understand your question. Are you intending to create a
> > new platform HAL package for STM3210C-EVAL?
> >
> >> Can someone modify this so I can update my CVS and work with the right code?
> > It will be no problem to extend the set of legal values for
> > CYGHWR_HAL_CORTEXM_STM32. Of course, you can make this change in your
> > local CVS checkout until you are ready to contribute your platform
> > support for STM3210C-EVAL.
> 
> Current STM32 code, as is, would not work for single chip configuration
> as it unconditionally depends on external RAM. In SIvA we have an
> internal modification that enables single chip operation and if there is
> an interest we would post a patch.
> 
It seems from reference manual that STM32 familly is almost compatible. On page 40 (RM) there is table with diffrences. The main issue is the interenal RAM and FLASH memmory. The FLASH is not a big problem (probably code will work just fine - I'm working with STM32103VD with settings for VE), but the SRAM is a different matter. The stack is placed on the top of internal SRAM memmory so you have to change the size of internal SRAM. This can be done in \packages\hal\cortexm\stm32\stm3210e_eval\current\include\pkgconf *.ldi and *.h files. The build configuration for connectivity line have to be set to ROM (Startup type) because this chip doesn't support FSMC. Next thing to do is to modyfy the stm3210e_eval_misc.c (remove the FSMC section).


    base = CYGHWR_HAL_STM32_GPIOA;
    HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_GPIO_CRL, 0x88888888 );
    HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_GPIO_CRH, 0x88888888 );
    
    base = CYGHWR_HAL_STM32_GPIOB;
    HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_GPIO_CRL, 0x88888888 );
    HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_GPIO_CRH, 0x88888888 );
    
    base = CYGHWR_HAL_STM32_GPIOC;
    HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_GPIO_CRL, 0x88888888 );
    HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_GPIO_CRH, 0x88888888 );
    
    base = CYGHWR_HAL_STM32_GPIOD;
    HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_GPIO_CRL, 0x88888888 );
    HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_GPIO_CRH, 0x88888888 );
    
    // Set up GPIO lines for external bus

-    base = CYGHWR_HAL_STM32_GPIOE;
-    HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_GPIO_CRL, 0xbbbbb4bb );
-    HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_GPIO_CRH, 0xbbbbbbbb );

-    base = CYGHWR_HAL_STM32_GPIOF;
-    HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_GPIO_CRL, 0x44bbbbbb );
-   HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_GPIO_CRH, 0xbbbb4444 );

-    base = CYGHWR_HAL_STM32_GPIOG;
-    HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_GPIO_CRL, 0x44bbbbbb );
-    HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_GPIO_CRH, 0x44444bb4 );

    
-   // Set up FSMC NOR/SRAM bank 2 for NOR Flash

-    base = CYGHWR_HAL_STM32_FSMC;

-    HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_FSMC_BCR2, 0x00001059 );
-    HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_FSMC_BTR2, 0x10000705 );

-    // Set up FSMC NOR/SRAM bank 3 for SRAM

-    HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_FSMC_BCR3, 0x00001011 );
-    HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_FSMC_BTR3, 0x00000200 );


There is only one thing left - the RCC differences. In RM there is a seperate section about RCC config for CL. But at the first look it seems that registers are compatible.

Summary I think that for CL there is no need for creating new port but to modyfy existing one for new internal FLASH and SRAM and without FSMC module.

P.S.
If some is intereseted I have driver for UART with REMAP option and SYNC mode. Also I have I2C driver. Both drivers are tested.

Best regards 
Qber

Re: STM32F107 on STM3210C-EVAL

[jerzy dyrda]

Hello all,

On Monday 28 March 2011 11:51:45 qber_@poczta.onet.pl wrote:
(...)
> There is only one thing left - the RCC differences. In RM there is a
> seperate section about RCC config for CL. But at the first look it seems
> that registers are compatible.
RCC registers are extended to support 2 extra PPL's with appropriate divider and multiplier.
Main differences is that source of PLL clock it isn't anymore taken directly from HSE or HSE/2 clock 
but it's introduced new divider PREDIV1 thus PLLSRC bit in RCC_CFGR register has partially 
different meaning. And another issue is external crystal. It value is 25MHz not 8 MHz like in 
STM3210E what causes need of using second PLL to produce CPU 72MHz.

HSE == 25MHz   /  PREDIV2 == 5 -> 5MHz   *  PLLMUL2 == 8 ->  
40MHz / PREDIV1 == 5 -> 8MHz * PLLMUL == 9 -> 72MHz = SYSCLK

It's looks ugly but above method it's used in ST source code for STM3210C evaluation board.

Best regards
jerzy

Re: STM32F107 on STM3210C-EVAL

[Ilija Kocho]

On 28.03.2011 11:51, qber_@poczta.onet.pl wrote:
> Hi
>
> W dniu 2011-03-26 12:07:30 użytkownik Ilija Kocho <ilijak@siva.com.mk> napisał:
>> On 23.03.2011 11:50, John Dallaway wrote:
>>> Hi Gian Maria
>>>
>>> Gian Maria wrote:
>>>
>>>> I'm porting eCos to STM3210C and I find a logical error on the
>>>> implementation of CYGPKG_HAL_CORTEXM_STM32.
>>>> CYGPKG_HAL_CORTEXM_STM32 must be the base of all STM32 uP and so is not
>>>> correct for me to use
>>>>
>>>>     cdl_option CYGHWR_HAL_CORTEXM_STM32 {
>>>>         display          "STM32 variant in use"
>>>>         flavor           data
>>>>         default_value    {"F103ZE"}
>>>>         legal_values     {"F103RC" "F103VC" "F103ZC"
>>>>                           "F103RD" "F103VD" "F103ZD"
>>>>                           "F103RE" "F103VE" "F103ZE" }
>>>>         description      "The STM32 has several variants, the main differences
>>>>                           being in the size of on-chip FLASH and SRAM
>>>>                           and numbers of some peripherals. This option
>>>>                           allows the platform HAL to select the specific
>>>>                           microcontroller fitted."
>>>>     }
>>>>
>>>> That is inside "ecoscvs\ecos\packages\hal\cortexm\stm32\var\current\cdl",
>>>> because with my EVB for example 
>>>> the uP is a STM32F107VC. With this I can't set the right uP as default for
>>>> the template.
>>>> I'm right? I think the correct is to put the code inside
>>>> "ecoscvs\ecos\packages\hal\cortexm\stm32\stm3210e_eval\current\cdl"
>>> I am not sure I understand your question. Are you intending to create a
>>> new platform HAL package for STM3210C-EVAL?
>>>
>>>> Can someone modify this so I can update my CVS and work with the right code?
>>> It will be no problem to extend the set of legal values for
>>> CYGHWR_HAL_CORTEXM_STM32. Of course, you can make this change in your
>>> local CVS checkout until you are ready to contribute your platform
>>> support for STM3210C-EVAL.
>> Current STM32 code, as is, would not work for single chip configuration
>> as it unconditionally depends on external RAM. In SIvA we have an
>> internal modification that enables single chip operation and if there is
>> an interest we would post a patch.
>>
> It seems from reference manual that STM32 familly is almost compatible. On page 40 (RM) there is table with diffrences. The main issue is the interenal RAM and FLASH memmory. The FLASH is not a big problem (probably code will work just fine - I'm working with STM32103VD with settings for VE), but the SRAM is a different matter. The stack is placed on the top of internal SRAM memmory so you have to change the size of internal SRAM. This can be done in \packages\hal\cortexm\stm32\stm3210e_eval\current\include\pkgconf *.ldi and *.h files. The build configuration for connectivity line have to be set to ROM (Startup type) because this chip doesn't support FSMC. Next thing to do is to modyfy the stm3210e_eval_misc.c (remove the FSMC section).
>
>
>     base = CYGHWR_HAL_STM32_GPIOA;
>     HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_GPIO_CRL, 0x88888888 );
>     HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_GPIO_CRH, 0x88888888 );
>     
>     base = CYGHWR_HAL_STM32_GPIOB;
>     HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_GPIO_CRL, 0x88888888 );
>     HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_GPIO_CRH, 0x88888888 );
>     
>     base = CYGHWR_HAL_STM32_GPIOC;
>     HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_GPIO_CRL, 0x88888888 );
>     HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_GPIO_CRH, 0x88888888 );
>     
>     base = CYGHWR_HAL_STM32_GPIOD;
>     HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_GPIO_CRL, 0x88888888 );
>     HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_GPIO_CRH, 0x88888888 );
>     
>     // Set up GPIO lines for external bus
>
> -    base = CYGHWR_HAL_STM32_GPIOE;
> -    HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_GPIO_CRL, 0xbbbbb4bb );
> -    HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_GPIO_CRH, 0xbbbbbbbb );
>
> -    base = CYGHWR_HAL_STM32_GPIOF;
> -    HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_GPIO_CRL, 0x44bbbbbb );
> -   HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_GPIO_CRH, 0xbbbb4444 );
>
> -    base = CYGHWR_HAL_STM32_GPIOG;
> -    HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_GPIO_CRL, 0x44bbbbbb );
> -    HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_GPIO_CRH, 0x44444bb4 );
>
>     
> -   // Set up FSMC NOR/SRAM bank 2 for NOR Flash
>
> -    base = CYGHWR_HAL_STM32_FSMC;
>
> -    HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_FSMC_BCR2, 0x00001059 );
> -    HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_FSMC_BTR2, 0x10000705 );
>
> -    // Set up FSMC NOR/SRAM bank 3 for SRAM
>
> -    HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_FSMC_BCR3, 0x00001011 );
> -    HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_FSMC_BTR3, 0x00000200 );
>
>

That's basically it. In addition in mlt files rename SRAM to RAM in
order to preserve GDB stubs / RedBoot functionality.

FSMC by default should be enabled (backward compatibility) for devices
that have it, but there should be an option to enforce disabling.

> There is only one thing left - the RCC differences. In RM there is a seperate section about RCC config for CL. But at the first look it seems that registers are compatible.
>
> Summary I think that for CL there is no need for creating new port but to modyfy existing one for new internal FLASH and SRAM and without FSMC module.
>
+1 from me. Changes to the variant are small and easy to implement.

Ilija

R: STM32F107 on STM3210C-EVAL

[Gian Maria]

I agree with you for HSE configuration, for my opinion this type of settings
that are not common to all STM32 must be put under specific EVB.
Connectivity line is a little bit different respect other STM32.
For my tests I have implemented a new option like

        cdl_option CYGHWR_HAL_CORTEXM_STM32_CLOCK_HCLK_DIV2 {
            display         "HCLK divider 2"
            flavor          data
            default_value   5
            legal_values    { 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 }
        }

And made a restriction in the EVB to set the right value
 
    requires      { CYGHWR_HAL_CORTEXM_STM32_CLOCK_PLL_DIV2 == 5}


In this way I can control the configuration, but I don't have to modify much
the original cdl.

My idea is to make STM3210C-EVAL running with eCos and RedBoot when all is
working I want to upload it, but I'm at the beginning and I have to study a
lot of eCos platform so I don't have a date.

Best regards Gian



-----Messaggio originale-----
Da: ecos-devel-owner@ecos.sourceware.org
[mailto:ecos-devel-owner@ecos.sourceware.org] Per conto di jerzy dyrda
Inviato: lunedì 28 marzo 2011 12:47
A: ecos-devel@ecos.sourceware.org; Gian Maria
Oggetto: Re: STM32F107 on STM3210C-EVAL

Hello all,

On Monday 28 March 2011 11:51:45 qber_@poczta.onet.pl wrote:
(...)
> There is only one thing left - the RCC differences. In RM there is a
> seperate section about RCC config for CL. But at the first look it seems
> that registers are compatible.
RCC registers are extended to support 2 extra PPL's with appropriate divider
and multiplier.
Main differences is that source of PLL clock it isn't anymore taken directly
from HSE or HSE/2 clock 
but it's introduced new divider PREDIV1 thus PLLSRC bit in RCC_CFGR register
has partially 
different meaning. And another issue is external crystal. It value is 25MHz
not 8 MHz like in 
STM3210E what causes need of using second PLL to produce CPU 72MHz.

HSE == 25MHz   /  PREDIV2 == 5 -> 5MHz   *  PLLMUL2 == 8 ->  
40MHz / PREDIV1 == 5 -> 8MHz * PLLMUL == 9 -> 72MHz = SYSCLK

It's looks ugly but above method it's used in ST source code for STM3210C
evaluation board.

Best regards
jerzy

RE: Re: STM32F107 on STM3210C-EVAL

[mlazcoz]

Hi Qber,

I'm porting eCos to an STM3210C-eval fake board. I have started with system
clocks until I've realized that all the job is already done by you! If you
dont mind, could you send me a patch? 
Thanks a lot,

mlazcoz


qber_ wrote:
> 
> Hi
> 
> W dniu 2011-03-26 12:07:30 użytkownik Ilija Kocho <ilijak@siva.com.mk>
> napisał:
>> On 23.03.2011 11:50, John Dallaway wrote:
>> > Hi Gian Maria
>> >
>> > Gian Maria wrote:
>> >
>> >> I'm porting eCos to STM3210C and I find a logical error on the
>> >> implementation of CYGPKG_HAL_CORTEXM_STM32.
>> >> CYGPKG_HAL_CORTEXM_STM32 must be the base of all STM32 uP and so is
>> not
>> >> correct for me to use
>> >>
>> >>     cdl_option CYGHWR_HAL_CORTEXM_STM32 {
>> >>         display          "STM32 variant in use"
>> >>         flavor           data
>> >>         default_value    {"F103ZE"}
>> >>         legal_values     {"F103RC" "F103VC" "F103ZC"
>> >>                           "F103RD" "F103VD" "F103ZD"
>> >>                           "F103RE" "F103VE" "F103ZE" }
>> >>         description      "The STM32 has several variants, the main
>> differences
>> >>                           being in the size of on-chip FLASH and SRAM
>> >>                           and numbers of some peripherals. This option
>> >>                           allows the platform HAL to select the
>> specific
>> >>                           microcontroller fitted."
>> >>     }
>> >>
>> >> That is inside
>> "ecoscvs\ecos\packages\hal\cortexm\stm32\var\current\cdl",
>> >> because with my EVB for example 
>> >> the uP is a STM32F107VC. With this I can't set the right uP as default
>> for
>> >> the template.
>> >> I'm right? I think the correct is to put the code inside
>> >> "ecoscvs\ecos\packages\hal\cortexm\stm32\stm3210e_eval\current\cdl"
>> > I am not sure I understand your question. Are you intending to create a
>> > new platform HAL package for STM3210C-EVAL?
>> >
>> >> Can someone modify this so I can update my CVS and work with the right
>> code?
>> > It will be no problem to extend the set of legal values for
>> > CYGHWR_HAL_CORTEXM_STM32. Of course, you can make this change in your
>> > local CVS checkout until you are ready to contribute your platform
>> > support for STM3210C-EVAL.
>> 
>> Current STM32 code, as is, would not work for single chip configuration
>> as it unconditionally depends on external RAM. In SIvA we have an
>> internal modification that enables single chip operation and if there is
>> an interest we would post a patch.
>> 
> It seems from reference manual that STM32 familly is almost compatible. On
> page 40 (RM) there is table with diffrences. The main issue is the
> interenal RAM and FLASH memmory. The FLASH is not a big problem (probably
> code will work just fine - I'm working with STM32103VD with settings for
> VE), but the SRAM is a different matter. The stack is placed on the top of
> internal SRAM memmory so you have to change the size of internal SRAM.
> This can be done in
> \packages\hal\cortexm\stm32\stm3210e_eval\current\include\pkgconf *.ldi
> and *.h files. The build configuration for connectivity line have to be
> set to ROM (Startup type) because this chip doesn't support FSMC. Next
> thing to do is to modyfy the stm3210e_eval_misc.c (remove the FSMC
> section).
> 
> 
>     base = CYGHWR_HAL_STM32_GPIOA;
>     HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_GPIO_CRL, 0x88888888 );
>     HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_GPIO_CRH, 0x88888888 );
>     
>     base = CYGHWR_HAL_STM32_GPIOB;
>     HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_GPIO_CRL, 0x88888888 );
>     HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_GPIO_CRH, 0x88888888 );
>     
>     base = CYGHWR_HAL_STM32_GPIOC;
>     HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_GPIO_CRL, 0x88888888 );
>     HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_GPIO_CRH, 0x88888888 );
>     
>     base = CYGHWR_HAL_STM32_GPIOD;
>     HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_GPIO_CRL, 0x88888888 );
>     HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_GPIO_CRH, 0x88888888 );
>     
>     // Set up GPIO lines for external bus
> 
> -    base = CYGHWR_HAL_STM32_GPIOE;
> -    HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_GPIO_CRL, 0xbbbbb4bb );
> -    HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_GPIO_CRH, 0xbbbbbbbb );
> 
> -    base = CYGHWR_HAL_STM32_GPIOF;
> -    HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_GPIO_CRL, 0x44bbbbbb );
> -   HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_GPIO_CRH, 0xbbbb4444 );
> 
> -    base = CYGHWR_HAL_STM32_GPIOG;
> -    HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_GPIO_CRL, 0x44bbbbbb );
> -    HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_GPIO_CRH, 0x44444bb4 );
> 
>     
> -   // Set up FSMC NOR/SRAM bank 2 for NOR Flash
> 
> -    base = CYGHWR_HAL_STM32_FSMC;
> 
> -    HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_FSMC_BCR2, 0x00001059 );
> -    HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_FSMC_BTR2, 0x10000705 );
> 
> -    // Set up FSMC NOR/SRAM bank 3 for SRAM
> 
> -    HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_FSMC_BCR3, 0x00001011 );
> -    HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_FSMC_BTR3, 0x00000200 );
> 
> 
> There is only one thing left - the RCC differences. In RM there is a
> seperate section about RCC config for CL. But at the first look it seems
> that registers are compatible.
> 
> Summary I think that for CL there is no need for creating new port but to
> modyfy existing one for new internal FLASH and SRAM and without FSMC
> module.
> 
> P.S.
> If some is intereseted I have driver for UART with REMAP option and SYNC
> mode. Also I have I2C driver. Both drivers are tested.
> 
> Best regards 
> Qber
> 
> 
> 
> 
> 
> 

-- 
View this message in context: http://old.nabble.com/STM32F107-on-STM3210C-EVAL-tp31213227p31395908.html
Sent from the Sourceware - ecos-devel mailing list archive at Nabble.com.

RE: Re: STM32F107 on STM3210C-EVAL

[qber_]

Hello again

W dniu 2011-03-28 12:47:07 użytkownik jerzy dyrda <jerzdy@gmail.com> napisał:
> Hello all,
> 
> On Monday 28 March 2011 11:51:45 qber_@poczta.onet.pl wrote:
> (...)
> > There is only one thing left - the RCC differences. In RM there is a
> > seperate section about RCC config for CL. But at the first look it seems
> > that registers are compatible.
> RCC registers are extended to support 2 extra PPL's with appropriate divider and multiplier.
> Main differences is that source of PLL clock it isn't anymore taken directly from HSE or HSE/2 clock 
> but it's introduced new divider PREDIV1 thus PLLSRC bit in RCC_CFGR register has partially 
> different meaning. And another issue is external crystal. It value is 25MHz not 8 MHz like in 
> STM3210E what causes need of using second PLL to produce CPU 72MHz.
> 
> HSE == 25MHz   /  PREDIV2 == 5 -> 5MHz   *  PLLMUL2 == 8 ->  
> 40MHz / PREDIV1 == 5 -> 8MHz * PLLMUL == 9 -> 72MHz = SYSCLK
> 
> It's looks ugly but above method it's used in ST source code for STM3210C evaluation board.
> 

It's not quite true. According to scheme and RM the clock can be takien from PLL2 or HSE directly. This is configured in RCC_CFGR2 bit 16
PREDIV1_SRC. Only the crystal have to be replaced on PCB.
> Best regards
> jerzy
> 
> 
Best regards
Qber