From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7566 invoked by alias); 28 Mar 2011 09:55:10 -0000 Received: (qmail 7555 invoked by uid 22791); 28 Mar 2011 09:55:09 -0000 X-SWARE-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,BAYES_50,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_NONE,RFC_ABUSE_POST,TW_XB,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtpo21.poczta.onet.pl (HELO smtpo21.poczta.onet.pl) (213.180.142.152) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 28 Mar 2011 09:55:03 +0000 Received: from pkn7.m5r2.onet (pkn7.m5r2.onet [10.174.32.168]) by smtp.poczta.onet.pl (Onet) with ESMTP id 2876F20120CB7; Mon, 28 Mar 2011 11:51:46 +0200 (CEST) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Received: from [217.6.141.85] by pkn7.m5r2.onet via HTTP id 201102281151451917010001; Mon, 28 Mar 2011 11:51:45 +0200 From: qber_@poczta.onet.pl To: ecos-devel@ecos.sourceware.org,Ilija Kocho Date: Mon, 28 Mar 2011 09:55:00 -0000 Message-Id: <23118906-1707f2ce17e92d08d3084915122281bc@pkn7.m5r2.onet> Subject: RE: Re: STM32F107 on STM3210C-EVAL X-Onet-PMQ: ;217.6.141.85;DE;2 X-IsSubscribed: yes Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2011-03/txt/msg00034.txt.bz2 Hi W dniu 2011-03-26 12:07:30 u=C5=BCytkownik Ilija Kocho = napisa=C5=82: > 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 dif= ferences > >> being in the size of on-chip FLASH and SRAM > >> and numbers of some peripherals. This option > >> allows the platform HAL to select the specif= ic > >> microcontroller fitted." > >> } > >> > >> That is inside "ecoscvs\ecos\packages\hal\cortexm\stm32\var\current\cd= l", > >> because with my EVB for example=20 > >> 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. >=20 > 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. >=20 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 interena= l 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 th= e SRAM is a different matter. The stack is placed on the top of internal SR= AM memmory so you have to change the size of internal SRAM. This can be don= e in \packages\hal\cortexm\stm32\stm3210e_eval\current\include\pkgconf *.ld= i and *.h files. The build configuration for connectivity line have to be s= et 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 =3D CYGHWR_HAL_STM32_GPIOA; HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_GPIO_CRL, 0x88888888 ); HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_GPIO_CRH, 0x88888888 ); =20=20=20=20 base =3D CYGHWR_HAL_STM32_GPIOB; HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_GPIO_CRL, 0x88888888 ); HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_GPIO_CRH, 0x88888888 ); =20=20=20=20 base =3D CYGHWR_HAL_STM32_GPIOC; HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_GPIO_CRL, 0x88888888 ); HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_GPIO_CRH, 0x88888888 ); =20=20=20=20 base =3D CYGHWR_HAL_STM32_GPIOD; HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_GPIO_CRL, 0x88888888 ); HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_GPIO_CRH, 0x88888888 ); =20=20=20=20 // Set up GPIO lines for external bus - base =3D 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 =3D 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 =3D CYGHWR_HAL_STM32_GPIOG; - HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_GPIO_CRL, 0x44bbbbbb ); - HAL_WRITE_UINT32( base+CYGHWR_HAL_STM32_GPIO_CRH, 0x44444bb4 ); =20=20=20=20 - // Set up FSMC NOR/SRAM bank 2 for NOR Flash - base =3D 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 sepera= te section about RCC config for CL. But at the first look it seems that reg= isters are compatible. Summary I think that for CL there is no need for creating new port but to m= odyfy 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 mo= de. Also I have I2C driver. Both drivers are tested. Best regards=20 Qber