Re: STM32F107 on STM3210C-EVAL

[Ilija Kocho <ilijak@siva.com.mk>]

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