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 <ili...@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.
