RE: Re: STM32F107 on STM3210C-EVAL

[mlazcoz <miguel.lazcoz@ingeteam.com>]

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.