libopenstm32-devel Mailing List for libopenstm32 (Page 2)
Status: Inactive
Brought to you by:
uh1763
You can subscribe to this list here.
2010 |
Jan
(10) |
Feb
(8) |
Mar
(27) |
Apr
(2) |
May
(16) |
Jun
(1) |
Jul
|
Aug
(2) |
Sep
(4) |
Oct
(11) |
Nov
(3) |
Dec
(11) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2011 |
Jan
(18) |
Feb
(17) |
Mar
(5) |
Apr
(2) |
May
|
Jun
(4) |
Jul
(20) |
Aug
(1) |
Sep
(4) |
Oct
(3) |
Nov
(1) |
Dec
|
From: Uwe B. <bo...@el...> - 2011-07-05 16:16:00
|
Hello, please review appended patch and apply or let me know any possible problems Bye -- Uwe Bonnes bo...@el... Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- >From 4d43502a0f54559320901d25f109e2f10e757287 Mon Sep 17 00:00:00 2001 From: Uwe Bonnes <bo...@el...> Date: Sun, 3 Jul 2011 18:03:35 +0200 Subject: Add setup for 25 MHz external clock to 72 MHz system clock --- include/libopencm3/stm32/rcc.h | 1 + lib/stm32/rcc.c | 73 ++++++++++++++++++++++++++++++++++++++++ 2 files changed, 74 insertions(+), 0 deletions(-) diff --git a/include/libopencm3/stm32/rcc.h b/include/libopencm3/stm32/rcc.h index d000567..a14aecd 100644 --- a/include/libopencm3/stm32/rcc.h +++ b/include/libopencm3/stm32/rcc.h @@ -430,6 +430,7 @@ void rcc_clock_setup_in_hse_8mhz_out_24mhz(void); void rcc_clock_setup_in_hse_8mhz_out_72mhz(void); void rcc_clock_setup_in_hse_12mhz_out_72mhz(void); void rcc_clock_setup_in_hse_16mhz_out_72mhz(void); +void rcc_clock_setup_in_hse_25mhz_out_72mhz(void); void rcc_backupdomain_reset(void); #endif diff --git a/lib/stm32/rcc.c b/lib/stm32/rcc.c index 1da462a..90b2a69 100644 --- a/lib/stm32/rcc.c +++ b/lib/stm32/rcc.c @@ -753,6 +753,79 @@ void rcc_clock_setup_in_hse_16mhz_out_72mhz(void) rcc_ppre2_frequency = 72000000; } +void rcc_clock_setup_in_hse_25mhz_out_72mhz(void) +{ + /* Enable internal high-speed oscillator. */ + rcc_osc_on(HSI); + rcc_wait_for_osc_ready(HSI); + + /* Select HSI as SYSCLK source. */ + rcc_set_sysclk_source(RCC_CFGR_SW_SYSCLKSEL_HSICLK); + + /* Enable external high-speed oscillator 25MHz. */ + rcc_osc_on(HSE); + rcc_wait_for_osc_ready(HSE); + rcc_set_sysclk_source(RCC_CFGR_SW_SYSCLKSEL_HSECLK); + + /* + * Set prescalers for AHB, ADC, ABP1, ABP2. + * Do this before touching the PLL (TODO: why?). + */ + rcc_set_hpre(RCC_CFGR_HPRE_SYSCLK_NODIV); /* Set. 72MHz Max. 72MHz */ + rcc_set_adcpre(RCC_CFGR_ADCPRE_PCLK2_DIV8); /* Set. 9MHz Max. 14MHz */ + rcc_set_ppre1(RCC_CFGR_PPRE1_HCLK_DIV2); /* Set. 36MHz Max. 36MHz */ + rcc_set_ppre2(RCC_CFGR_PPRE2_HCLK_NODIV); /* Set. 72MHz Max. 72MHz */ + + /* + * Sysclk runs with 72MHz -> 2 waitstates. + * 0WS from 0-24MHz + * 1WS from 24-48MHz + * 2WS from 48-72MHz + */ + flash_set_ws(FLASH_LATENCY_2WS); + + /* Configure PLLs ------------------------------------------------------*/ + /* PLL2 configuration: PLL2CLK = (HSE / 5) * 8 = 40 MHz */ + /* PREDIV1 configuration: PREDIV1CLK = PLL2 / 5 = 8 MHz */ + + rcc_set_prediv2(RCC_CFGR2_PREDIV2_DIV5); + rcc_set_pll2mult(RCC_CFGR2_PLL2MUL_PLL2_CLK_MUL8); + rcc_set_prediv1src(RCC_CFGR2_PREDIV1SRC_PLL2_CLK); + rcc_set_prediv1(RCC_CFGR2_PREDIV1_DIV5); + + /* Enable PLL2 */ + rcc_osc_on(PLL2); + /* Wait till PLL2 is ready */ + rcc_wait_for_osc_ready(PLL2); + + + /* + * Set the PLL multiplication factor to 9. + * 8MHz (external) * 9 (multiplier) = 72MHz + */ + rcc_set_pll_multiplication_factor(RCC_CFGR_PLLMUL_PLL_CLK_MUL9); + + /* Select PREDIV as PLL source. */ + rcc_set_pll_source(RCC_CFGR_PLLSRC_PREDIV1_CLK); + + /* + * External frequency undivided before entering PLL + * (only valid/needed for HSE). + */ + rcc_set_pllxtpre(RCC_CFGR_PLLXTPRE_HSE_CLK); + + /* Enable PLL oscillator and wait for it to stabilize. */ + rcc_osc_on(PLL); + rcc_wait_for_osc_ready(PLL); + + /* Select PLL as SYSCLK source. */ + rcc_set_sysclk_source(RCC_CFGR_SW_SYSCLKSEL_PLLCLK); + + /* Set the peripheral clock frequencies used */ + rcc_ppre1_frequency = 36000000; + rcc_ppre2_frequency = 72000000; +} + void rcc_backupdomain_reset(void) { /* Set the backup domain software reset. */ -- 1.7.3.4 |
From: Uwe B. <bo...@el...> - 2011-07-05 16:15:33
|
Hello, please review appended patch and apply or let me know any possible problems Bye -- Uwe Bonnes bo...@el... Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- >From ba2d229f0eb4505be64d2e146f0897fa65c26358 Mon Sep 17 00:00:00 2001 From: Uwe Bonnes <bo...@el...> Date: Sun, 3 Jul 2011 18:02:48 +0200 Subject: Add definitions aroundRCC_CFGR2 and PLL2 --- include/libopencm3/stm32/rcc.h | 20 +++++++++- lib/stm32/rcc.c | 86 ++++++++++++++++++++++++++++++++++++++++ lib/stm32/rtc.c | 1 + 3 files changed, 106 insertions(+), 1 deletions(-) diff --git a/include/libopencm3/stm32/rcc.h b/include/libopencm3/stm32/rcc.h index 1072445..d000567 100644 --- a/include/libopencm3/stm32/rcc.h +++ b/include/libopencm3/stm32/rcc.h @@ -351,6 +351,24 @@ #define RCC_CFGR2_PLL2MUL_PLL2_CLK_MUL16 0xe #define RCC_CFGR2_PLL2MUL_PLL2_CLK_MUL20 0xf +/* PREDIV1: PREDIV1 division factor */ +#define RCC_CFGR2_PREDIV1_NODIV 0x0 +#define RCC_CFGR2_PREDIV1_DIV2 0x1 +#define RCC_CFGR2_PREDIV1_DIV3 0x2 +#define RCC_CFGR2_PREDIV1_DIV4 0x3 +#define RCC_CFGR2_PREDIV1_DIV5 0x4 +#define RCC_CFGR2_PREDIV1_DIV6 0x5 +#define RCC_CFGR2_PREDIV1_DIV7 0x6 +#define RCC_CFGR2_PREDIV1_DIV8 0x7 +#define RCC_CFGR2_PREDIV1_DIV9 0x8 +#define RCC_CFGR2_PREDIV1_DIV10 0x9 +#define RCC_CFGR2_PREDIV1_DIV11 0xa +#define RCC_CFGR2_PREDIV1_DIV12 0xb +#define RCC_CFGR2_PREDIV1_DIV13 0xc +#define RCC_CFGR2_PREDIV1_DIV14 0xd +#define RCC_CFGR2_PREDIV1_DIV15 0xe +#define RCC_CFGR2_PREDIV1_DIV16 0xf + /* PREDIV2: PREDIV2 division factor */ #define RCC_CFGR2_PREDIV2_NODIV 0x0 #define RCC_CFGR2_PREDIV2_DIV2 0x1 @@ -376,7 +394,7 @@ extern u32 rcc_ppre2_frequency; /* --- Function prototypes ------------------------------------------------- */ typedef enum { - PLL, HSE, HSI, LSE, LSI + PLL, HSE, HSI, LSE, LSI, PLL2 } osc_t; void rcc_osc_ready_int_clear(osc_t osc); diff --git a/lib/stm32/rcc.c b/lib/stm32/rcc.c index f646168..1da462a 100644 --- a/lib/stm32/rcc.c +++ b/lib/stm32/rcc.c @@ -44,6 +44,9 @@ void rcc_osc_ready_int_clear(osc_t osc) case LSI: RCC_CIR |= RCC_CIR_LSIRDYC; break; + case PLL2: + RCC_CIR |= RCC_CIR_PLL2RDYC; + break; } } @@ -65,6 +68,9 @@ void rcc_osc_ready_int_enable(osc_t osc) case LSI: RCC_CIR |= RCC_CIR_LSIRDYIE; break; + case PLL2: + RCC_CIR |= RCC_CIR_PLL2RDYIE; + break; } } @@ -86,6 +92,9 @@ void rcc_osc_ready_int_disable(osc_t osc) case LSI: RCC_CIR &= ~RCC_CIR_LSIRDYIE; break; + case PLL2: + RCC_CIR &= ~RCC_CIR_PLL2RDYIE; + break; } } @@ -107,6 +116,9 @@ int rcc_osc_ready_int_flag(osc_t osc) case LSI: return ((RCC_CIR & RCC_CIR_LSIRDYF) != 0); break; + case PLL2: + return ((RCC_CIR & RCC_CIR_PLL2RDYF) != 0); + break; } /* Shouldn't be reached. */ @@ -141,6 +153,9 @@ void rcc_wait_for_osc_ready(osc_t osc) case LSI: while ((RCC_CSR & RCC_CSR_LSIRDY) == 0); break; + case PLL2: + while ((RCC_CR & RCC_CR_PLL2RDY) == 0); + break; } } @@ -162,6 +177,9 @@ void rcc_osc_on(osc_t osc) case LSI: RCC_CSR |= RCC_CSR_LSION; break; + case PLL2: + RCC_CR |= RCC_CR_PLL2ON; + break; } } @@ -183,6 +201,9 @@ void rcc_osc_off(osc_t osc) case LSI: RCC_CSR &= ~RCC_CSR_LSION; break; + case PLL2: + RCC_CR &= ~RCC_CR_PLL2ON; + break; } } @@ -205,6 +226,7 @@ void rcc_osc_bypass_enable(osc_t osc) case LSE: RCC_BDCR |= RCC_BDCR_LSEBYP; break; + case PLL2: case PLL: case HSI: case LSI: @@ -223,6 +245,7 @@ void rcc_osc_bypass_disable(osc_t osc) RCC_BDCR &= ~RCC_BDCR_LSEBYP; break; case PLL: + case PLL2: case HSI: case LSI: /* Do nothing, only HSE/LSE allowed here. */ @@ -331,6 +354,69 @@ void rcc_set_usbpre(u32 usbpre) RCC_CFGR = (reg32 | (usbpre << 22)); } +void rcc_set_prediv2(u32 prediv2) +{ + u32 reg32; + + reg32 = RCC_CFGR2; + reg32 &= ~(0xf<<4); + RCC_CFGR2 = (reg32 | (prediv2 << 4)); +} + +void rcc_set_prediv1(u32 prediv1) +{ + u32 reg32; + + reg32 = RCC_CFGR2; + reg32 &= ~(0xf); + RCC_CFGR2 = (reg32 | prediv1); +} + +void rcc_set_pll2mult(u32 pll2mult) +{ + u32 reg32; + + reg32 = RCC_CFGR2; + reg32 &= ~(0xf << 8); + RCC_CFGR2 = (reg32 | (pll2mult << 8)); +} + +void rcc_set_pll3mult(u32 pll3mult) +{ + u32 reg32; + + reg32 = RCC_CFGR2; + reg32 &= ~(0xf << 12); + RCC_CFGR2 = (reg32 | (pll3mult << 12)); +} + +void rcc_set_prediv1src(u32 prediv1src) +{ + u32 reg32; + + reg32 = RCC_CFGR2; + reg32 &= ~(0x1 << 16); + RCC_CFGR2 = (reg32 | (prediv1src << 16)); +} + +void rcc_set_i2s2src(u32 i2s2src) +{ + u32 reg32; + + reg32 = RCC_CFGR2; + reg32 &= ~(0x1 << 17); + RCC_CFGR2 = (reg32 | (i2s2src << 17)); +} + +void rcc_set_i2s3src(u32 i2s3src) +{ + u32 reg32; + + reg32 = RCC_CFGR2; + reg32 &= ~(0x1 << 18); + RCC_CFGR2 = (reg32 | (i2s3src << 18)); +} + u32 rcc_system_clock_source(void) { /* Return the clock source which is used as system clock. */ diff --git a/lib/stm32/rtc.c b/lib/stm32/rtc.c index 4495641..bc9bf1e 100644 --- a/lib/stm32/rtc.c +++ b/lib/stm32/rtc.c @@ -67,6 +67,7 @@ void rtc_awake_from_off(osc_t clock_source) RCC_BDCR |= (1 << 9) | (1 << 8); break; case PLL: + case PLL2: case HSI: /* Unusable clock source, here to prevent warnings. */ /* Turn off clock sources to RTC. */ -- 1.7.3.4 |
From: Uwe B. <bo...@el...> - 2011-07-05 16:14:50
|
Hello, please review appended patch and apply or let me know any possible problems Bye -- Uwe Bonnes bo...@el... Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- >From d457832ed9efb372a8e110480bdbb7a6bc70fea3 Mon Sep 17 00:00:00 2001 From: Uwe Bonnes <bo...@el...> Date: Sun, 3 Jul 2011 18:00:06 +0200 Subject: Add more files to ignore --- .gitignore | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/.gitignore b/.gitignore index 947d5d2..42d6761 100644 --- a/.gitignore +++ b/.gitignore @@ -1,3 +1,4 @@ +*.d *.o *.bin *.hex -- 1.7.3.4 |
From: Uwe B. <bo...@el...> - 2011-07-05 16:09:02
|
Hello, please review appended patch and apply or let me know any possible problems Bye -- Uwe Bonnes bo...@el... Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- >From 667534eb9c614cea31362a8ad91affd60429205c Mon Sep 17 00:00:00 2001 From: Uwe Bonnes <bo...@el...> Date: Sun, 3 Jul 2011 18:00:06 +0200 Subject: Add more files to ignore --- .gitignore | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/.gitignore b/.gitignore index 947d5d2..42d6761 100644 --- a/.gitignore +++ b/.gitignore @@ -1,3 +1,4 @@ +*.d *.o *.bin *.hex -- 1.7.3.4 |
From: Gareth M. <ga...@bl...> - 2011-06-28 10:23:50
|
On Mon, Jun 27, 2011 at 11:00 AM, Matjaz Janezic <ja...@gm...> wrote: > is where tutorial how to build this library with yagarto tools? I don't think so. Windows isn't the friendliest build environment. I built a Windows toolchain with a modified summon-arm-toolchain including libopenstm32: http://www.blacksphere.co.nz/downloads/sat-w32-0a.exe This was cross-compiled from Linux. I can't help with a native Windows build. Regards, Gareth -- Black Sphere Technologies Ltd. Web: www.blacksphere.co.nz Mobile: +64 27 777 2182 Tel: +64 9 478 8885 Skype: gareth.mcmullin LinkedIn: http://nz.linkedin.com/in/gsmcmullin |
From: Matjaz J. <ja...@gm...> - 2011-06-26 23:00:18
|
Hi, is where tutorial how to build this library with yagarto tools? best regards, Matjaz |
From: Nico v. G. <Nic...@FU...> - 2011-06-14 19:50:03
|
Hey. I'm currently working with libopenstm32 on a stm32-h107 dev board. It's great, but I have some problemes here and there: When I try to configure some USARTs (1&2) I have to divide the baud rate by two to get a working serial connection (my baud rate is 921600 on USART1 => usart_set_baudrate(USART1, 921600 / 2); and 1MB on USART2 => usart_set_baudrate(USART1, 1000000 / 2) ). Now I can communicate with the uc, but after an unknown amount of time the serial connection is not working anymore for some seconds. I thought it may be an inaccurate baud rate, so I checked the values in USART_BRR. For USART1 there is 9.12 and for USART2 4,8. By using the formula of the reference manual (baud = f_clk/(16*usart_brr)) or the table 189 on page 748, I get the following values: USART1: 921600 = 72000000/(16*4,875) USART2: 1000000 = 36000000 / (16*2,25) I'm suprised that I actually have a working connection for about 90% of time, but I think either I made a math error or something else is wrong here. Does anybody has a hint? Greetins Nico . |
From: .: f. :. <fo...@me...> - 2011-06-14 13:37:26
|
Hi guys... I'm in trouble with SPI1 of my cortexm3. I'm trying only to send some packet on the line and to view it trhrough oscilloscope. Can you take a look to my code? I'm going crazy. http://pastie.org/2066599 Thanks in advance Roberto P.S. Is there working example about SPI using libopenstm32? I found it in examples/stm32/stm32-h103/spi but is not complete. -- Roberto (aka formica) Marino Computer Engineer FSF Member #9647 - Me|Lug Member http://people.gnudev.org/~formica/ Mobile: 349-5740870 |
From: Uwe H. <uw...@he...> - 2011-04-28 17:55:15
|
On Sun, Apr 24, 2011 at 02:48:09PM +1200, Gareth McMullin wrote: > I've finally done some finishing touches and testing of the > connectivity line usb support. There are also a number > of other minor changes I've pushed to: > gi...@gi...:gsmcmullin/libusbdev.git > > If there are no objections, can these please be pulled to > the mainstream. Thanks, merged. Please let me know if there were any merge issues. Uwe. -- http://hermann-uwe.de | http://sigrok.org http://randomprojects.org | http://unmaintained-free-software.org |
From: Gareth M. <ga...@bl...> - 2011-04-24 03:11:37
|
Hi All I've finally done some finishing touches and testing of the connectivity line usb support. There are also a number of other minor changes I've pushed to: gi...@gi...:gsmcmullin/libusbdev.git If there are no objections, can these please be pulled to the mainstream. Regards, Gareth -- Black Sphere Technologies Ltd. Web: www.blacksphere.co.nz Mobile: +64 27 777 2182 Tel: +64 9 478 8885 Skype: gareth.mcmullin LinkedIn: http://nz.linkedin.com/in/gsmcmullin |
From: Gareth M. <ga...@bl...> - 2011-03-19 01:22:06
|
Hi all I have got the connectivity line usb driver to a functional level. Is not finished and has a few limitations, but should work with the existing usb examples in the source tree (you'll need to change them to actually use this driver though.) The code is in my git repo: git://github.com/gsmcmullin/libusbdev.git I have also added a simple example of a USB controlled led. This is the simplest usb device that actually does something. With it is a Python (PyUSB + PyGTK) script to control the device. For now, the driver doesn't set up interrupts properly, so don't try usbd_poll from the irq handler. Some functions like suspend and resume aren't implemented yet. I'm interested if anyone has any ideas on the following: The connectivity line devices use a shared receive fifo for all endpoints. This requires the application to read the packets in the order they are received, so all OUT endpoints must have callback functions to read the data. In some applications it is easier to have usbd_poll() called in an interrupt handler to process standard requests, and have usbd_ep_packet_read called from the application to poll for data on a bulk endpoint. I can't think of a nice way to do this. Another problem is that there is no way to flow control an OUT endpoint. With the F103 driver NAKs will be sent until the application reads the packet, with this driver this approach will prevent all usb out/setup requests. Should new functions be added to force an endpoint to send the NAK handshake? Regards, Gareth -- Black Sphere Technologies Ltd. Web: www.blacksphere.co.nz Mobile: +64 27 777 2182 Tel: +64 9 478 8885 Skype: gareth.mcmullin LinkedIn: http://nz.linkedin.com/in/gsmcmullin |
From: Piotr Esden-T. <pi...@es...> - 2011-03-13 19:57:39
|
Hi! On Mar 12, 2011, at 4:52 PM, Gareth McMullin wrote: > On Thu, Mar 10, 2011 at 2:34 AM, Nico von Geyso <Nic...@fu...> wrote: >> I had some problems with the usart_set_baudrate() function and so I took >> a deeper look how it works. >> The baud rade generation for stm32 is described in the section >> "Fractional baud rate generation" in RM0008 Reference manual, Page 747. > > If I read it correctly, all the talk in the manual makes it sound fancy and > complicated, but the simple division calculates the correct value. Yes that is what I figured myself. This sounds like marketting talk to make the divider sound more awesome than it is. :) I updated the rcc code to store the clock speeds of the apb1 and apb2 into variables and use them to calculate the baud divider, using just a simple division. Tested it a little and it seems to work like a charm. just pull from my fork repository and give it a try. :) > >> For the stm-h107 development the current implementation works fine for >> usart 2,3 but not for usart1. >> Usart1 has a different clock source (PCLK2, 72Mhz) and so you have to >> divide the baud parameter (for usart_set_baudrate(...)) by two to get >> the correct values. >> As it is hard to get the current pclk1 or pclk2 values, wouldn't it be >> better if there is a function like the following: >> >> void usart_set_baudrate(u32 clock, u32 usart, u32 baud); //set the >> clock manually > > I think this is the most obvious way to do it. I would swap the clock and usart > parameters though. I think it is better to track the clock speed of the system and have the baud rate still be calculated automatically... Cheers Esden -- Blog: http://www.esden.net Projects: http://open-bldc.org http://paparazziuav.org http://github.org/esden/floss-jtag http://github.org/esden/summon-arm-toolchain |
From: Gareth M. <ga...@bl...> - 2011-03-13 01:13:19
|
Hi I'd like to propose some changes to the build system. I've found there is too much cutting and pasting in adding an example. I've pushed some proposed changes to: git://github.com/gsmcmullin/libusbdev.git The examples and libraries for the various targets are built with for loops in the top-level Makefile. To add an example you just need to create the directory in the right place and it will automatically be included in the build. I also think that the 3 Makefile.includes should possibly be replaced by a single one. Please let me know if anyone has any comments. If everyone is happy with this approach it can be pulled into the main repository. Regards, Gareth -- Black Sphere Technologies Ltd. Web: www.blacksphere.co.nz Mobile: +64 27 777 2182 Tel: +64 9 478 8885 Skype: gareth.mcmullin LinkedIn: http://nz.linkedin.com/in/gsmcmullin |
From: Gareth M. <ga...@bl...> - 2011-03-13 00:53:06
|
On Thu, Mar 10, 2011 at 2:34 AM, Nico von Geyso <Nic...@fu...> wrote: > I had some problems with the usart_set_baudrate() function and so I took > a deeper look how it works. > The baud rade generation for stm32 is described in the section > "Fractional baud rate generation" in RM0008 Reference manual, Page 747. If I read it correctly, all the talk in the manual makes it sound fancy and complicated, but the simple division calculates the correct value. > For the stm-h107 development the current implementation works fine for > usart 2,3 but not for usart1. > Usart1 has a different clock source (PCLK2, 72Mhz) and so you have to > divide the baud parameter (for usart_set_baudrate(...)) by two to get > the correct values. > As it is hard to get the current pclk1 or pclk2 values, wouldn't it be > better if there is a function like the following: > > void usart_set_baudrate(u32 clock, u32 usart, u32 baud); //set the > clock manually I think this is the most obvious way to do it. I would swap the clock and usart parameters though. Regards, Gareth -- Black Sphere Technologies Ltd. Web: www.blacksphere.co.nz Mobile: +64 27 777 2182 Tel: +64 9 478 8885 Skype: gareth.mcmullin LinkedIn: http://nz.linkedin.com/in/gsmcmullin |
From: Nico v. G. <Nic...@FU...> - 2011-03-09 13:34:20
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey, I had some problems with the usart_set_baudrate() function and so I took a deeper look how it works. The baud rade generation for stm32 is described in the section "Fractional baud rate generation" in RM0008 Reference manual, Page 747. To set the baud rate for the stm32 boards, you have to set the correct unsigned fixed point number (fraction and mantissa) USARTDIV in USART_BRR. USART_BRR is a 32 Bit Register and divided into the following regions: Bit 3:0 DIV_FRACTION of USARTDIV Bit 15:4 DIV_MANTISSA of USARTDIV BIT 16:31 reserverd formula for baud rate Baud = f_ck / (16 * USARTDIV) , f_ck = PCLK1 (for USART 2,3,4,5, max 36MHz) or PCLK2 (for USART 1, max 72Mhz) => USARTDIV = f_ck / (16 * BAUD) We have to set the mantissa and fraction of USARTDIV in USART_BRR DIV_Mantissa = (u16) f_ck / (16* BAUD) -- USART_DIV value before the comma DIV_Fraction = f_ck / (16* BAUD) - DIV_Mantissa -- USART_DIV value after the comma To set the baud rate we have to form the correct unsigned fixed point number. For that we have to combine DIV_Mantissa and DIV_Fraction. The first four bits are for the fraction value and the next 11 bits are for the mantissa (for that shift DIV_Mantissa 4 times). USART_BRR = (DIV_MANTISSA << 4) | DIV_FRACTION the current implementation in lib/stm32/lib/usart.c: void usart_set_baudrate(u32 usart, u32 baud) { u32 clock = 72000000; /* FIXME: Don't hardcode this clock! */ /* TODO: Document and explain calculation. */ USART_BRR(usart) = (u16)((clock << 4) / (baud * 16)); } The assignment in the function does the calculation and the shift in one step but ignores the fraction value. With that I think you can not set all possible baud rate values... USART_BRR(usart) = (clock << 4) / (baud * 16) For the stm-h107 development the current implementation works fine for usart 2,3 but not for usart1. Usart1 has a different clock source (PCLK2, 72Mhz) and so you have to divide the baud parameter (for usart_set_baudrate(...)) by two to get the correct values. As it is hard to get the current pclk1 or pclk2 values, wouldn't it be better if there is a function like the following: void usart_set_baudrate(u32 clock, u32 usart, u32 baud); //set the clock manually or void rcc_get_pclkX(); //to get the clock for the calculation Then you don't have to hardcode the clock. Greetings Nico -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNd4HUAAoJEBnE9vofeFrkc2kH+QHE8x+u7pCcvCrsysU64b9v 2Bf923Bjuzfjs6uNN2vw2RUuYl+7wXhNdgYhcGvKcyIDvlCT3oYLsPSmt6DCo0Gb o/W/isET4bd9dthu0lvAGmiBAOHsgTfv8IaiqvhrlDLTQdCp/QiJqLNPHrkczKBb IJ9HFFSMkTu+vK8l4KH+UcMpcw0ZVH7V3pS40illHLQmqiae5X7N1LyjutDI9H9d Ikzf9wE4zPXBNWCZ1kUB7qLAWpjUcgm2qCXnnwQed7vy/g7VUg13eV2eQQUdnTbz 5uvEgecyvJ2vrlAeFCxGXdUDOVke8xyw/IPOc1qFF/CsdTEB1LWVvWmBnL2Raik= =0oHY -----END PGP SIGNATURE----- |
From: Gareth M. <ga...@bl...> - 2011-02-27 01:33:36
|
Hi As I've mentioned before, I've been working on a new debugging tool for the Cortex-M3. This is a hardware/firmware solution that implements a GDB server over USB. It currently supports the STM32 and LM3S families of devices. I've setup the SF project: project page: https://sourceforge.net/projects/blackmagicdebug/ project wiki: https://sourceforge.net/apps/mediawiki/blackmagicdebug/ website: http://www.blacksphere.co.nz/main/blackmagic mailing-list: https://sourceforge.net/mail/?group_id=407419 The firmware can also be built as an application using an FT2232 device to implement the JTAG or SWD interfaces. This has been tested using the Floss-JTAG under Linux and MacOS. See the project wiki for more info. If you do try it out please let me know what you think. Any comments would be appreciated. Thank you, Esden, for your input so far. Regards, Gareth -- Black Sphere Technologies Ltd. Web: www.blacksphere.co.nz Mobile: +64 27 777 2182 Tel: +64 9 478 8885 Skype: gareth.mcmullin LinkedIn: http://nz.linkedin.com/in/gsmcmullin |
From: Piotr Esden-T. <pi...@es...> - 2011-02-17 19:03:43
|
Hi everyone, On Feb 15, 2011, at 3:32 PM, Bernard Davison wrote: > Another thing to note when working with the tool chain / gcc is that when you compile you need to make sure that the linker is including the correct multilibs. > To find the options that you need do the following. > arm-none-eabi-gcc -print-multi-lib > This will print something like: > .;@msoft-float > thumb;@mthumb@msoft-float > thumb/v7;@mthumb@march=armv7@msoft-float > armv4t;@mthumb@march=armv4t@msoft-float > thumb2;@mthumb@march=armv7@mfix-cortex-m3-ldrd@msoft-float Just as a heads up. I added multilib support to SAT (https://github.com/esden/summon-arm-toolchain) now it should generate all the libraries with the correct parameters. > If we want / need to include the thumb2 versions of the multilibs then we must specify every option for that library set. > i.e. -mthumb -march=arm7 -mfix-cortex-m3-ldrd -msoft-float > Note that what you have will be different from the above and will need adjusting accordingly. I tested a little bit and the flags necessary to build the right assembler and link with the correct multilib are the following: CFLAGS=-mcpu=cortex-m3 -mthumb -msoft-float LDFLAGS=-mthumb -march=armv7 -mfix-cortex-m3-ldrd -msoft-float > The alternative to this is to build gcc so that it only supports the target architecture. (This is NOT what the summon-arm-toolchain currently does) You should be able to generate just that by passing DEFAULT_TO_CORTEX_M3=1 to the SAT script. Please tell me if the parameters passed in there are not correct for someone. > Please let me know if you have any questions. Thank you for your and Eric Parsonage work on that. The changes in SAT are based on your work. I hope that solves the problems for most people if not everyone. :) > > Cheers, > Bernie. > > On 16/02/2011, at 7:33 AM, Gareth McMullin wrote: > >> On Wed, Feb 16, 2011 at 8:38 AM, Gareth McMullin >> <ga...@bl...> wrote: >>> Ok, there seems to be a lurking bug in the USB code. You aren't the >>> first person to have this problem. I unfortunately can't reproduce the >>> problem with either of the two hosts I have available. >> >> I've found the problem: just tried building with summon-arm-toolchain, >> and I observe the same problem. The build_config_descriptor() function >> uses memcpy() to contruct the configuration descriptor, on entry to memcpy >> an invalid instruction is encountered and the target is found in >> blocking_handler(). >> No further USB requests are handled. >> >> It seems that summon-arm-toolchain is linking in an ARM mode memcpy >> instead of thumb. This can be solved by adding -mthumb to the linker >> options. >> >> I've attached a patch to the generic makefile, which just added the full CFLAGS >> to the linker command line. It solved the problem and should be safe. >> I've also removed the "-Wl,--gc-sections", and changed options to "-O0 -g3". >> The options in git make the examples very hard to debug, and I think this >> may create a barrier to newbies trying out the library. Especially >> for an example, >> we can give up some size to make things easier. >> >> Regards, >> Gareth Cheers Esden -- Blog: http://www.esden.net Projects: http://open-bldc.org http://paparazziuav.org http://github.org/esden/floss-jtag http://github.org/esden/summon-arm-toolchain |
From: gwenhael.goavec <gwe...@fe...> - 2011-02-17 13:37:32
|
On Wed, 16 Feb 2011 09:33:54 +1300 Gareth McMullin <ga...@bl...> wrote: > On Wed, Feb 16, 2011 at 8:38 AM, Gareth McMullin > <ga...@bl...> wrote: > > Ok, there seems to be a lurking bug in the USB code. You aren't the > > first person to have this problem. I unfortunately can't reproduce the > > problem with either of the two hosts I have available. > > I've found the problem: just tried building with summon-arm-toolchain, > and I observe the same problem. The build_config_descriptor() function > uses memcpy() to contruct the configuration descriptor, on entry to memcpy > an invalid instruction is encountered and the target is found in > blocking_handler(). > No further USB requests are handled. > > It seems that summon-arm-toolchain is linking in an ARM mode memcpy > instead of thumb. This can be solved by adding -mthumb to the linker > options. > > I've attached a patch to the generic makefile, which just added the full CFLAGS > to the linker command line. It solved the problem and should be safe. > I've also removed the "-Wl,--gc-sections", and changed options to "-O0 -g3". > The options in git make the examples very hard to debug, and I think this > may create a barrier to newbies trying out the library. Especially > for an example, > we can give up some size to make things easier. > > Regards, > Gareth > Hi, I have just tested after having applied the patch. This ok! Thank you ! Regards, Gwenhaël |
From: Gareth M. <ga...@bl...> - 2011-02-17 09:00:52
|
Hi I've written register definitions for the Instrumentation Trace Macrocell (ITM) and Trace Port Interface Unit (TPIU) and a a basic example to transmit characters on the TRACESWO pin. I've pushed to my github repo: git://github.com/gsmcmullin/libusbdev.git There are also some minor cosmetic changes to the usb code, and a template driver for the STM32F10[57] series. I'm working on the implementation of this driver, amongst other things. Regards, Gareth -- Black Sphere Technologies Ltd. Web: www.blacksphere.co.nz Mobile: +64 27 777 2182 Tel: +64 9 478 8885 Skype: gareth.mcmullin LinkedIn: http://nz.linkedin.com/in/gsmcmullin |
From: Bernard D. <be...@go...> - 2011-02-16 00:02:10
|
Another thing to note when working with the tool chain / gcc is that when you compile you need to make sure that the linker is including the correct multilibs. To find the options that you need do the following. arm-none-eabi-gcc -print-multi-lib This will print something like: .;@msoft-float thumb;@mthumb@msoft-float thumb/v7;@mthumb@march=armv7@msoft-float armv4t;@mthumb@march=armv4t@msoft-float thumb2;@mthumb@march=armv7@mfix-cortex-m3-ldrd@msoft-float If we want / need to include the thumb2 versions of the multilibs then we must specify every option for that library set. i.e. -mthumb -march=arm7 -mfix-cortex-m3-ldrd -msoft-float Note that what you have will be different from the above and will need adjusting accordingly. The alternative to this is to build gcc so that it only supports the target architecture. (This is NOT what the summon-arm-toolchain currently does) Please let me know if you have any questions. Cheers, Bernie. On 16/02/2011, at 7:33 AM, Gareth McMullin wrote: > On Wed, Feb 16, 2011 at 8:38 AM, Gareth McMullin > <ga...@bl...> wrote: >> Ok, there seems to be a lurking bug in the USB code. You aren't the >> first person to have this problem. I unfortunately can't reproduce the >> problem with either of the two hosts I have available. > > I've found the problem: just tried building with summon-arm-toolchain, > and I observe the same problem. The build_config_descriptor() function > uses memcpy() to contruct the configuration descriptor, on entry to memcpy > an invalid instruction is encountered and the target is found in > blocking_handler(). > No further USB requests are handled. > > It seems that summon-arm-toolchain is linking in an ARM mode memcpy > instead of thumb. This can be solved by adding -mthumb to the linker > options. > > I've attached a patch to the generic makefile, which just added the full CFLAGS > to the linker command line. It solved the problem and should be safe. > I've also removed the "-Wl,--gc-sections", and changed options to "-O0 -g3". > The options in git make the examples very hard to debug, and I think this > may create a barrier to newbies trying out the library. Especially > for an example, > we can give up some size to make things easier. > > Regards, > Gareth > > -- > Black Sphere Technologies Ltd. > > Web: www.blacksphere.co.nz > Mobile: +64 27 777 2182 > Tel: +64 9 478 8885 > Skype: gareth.mcmullin > LinkedIn: http://nz.linkedin.com/in/gsmcmullin > <sat-patch>------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb_______________________________________________ > libopenstm32-devel mailing list > lib...@li... > https://lists.sourceforge.net/lists/listinfo/libopenstm32-devel |
From: Gareth M. <ga...@bl...> - 2011-02-15 21:03:16
|
On Wed, Feb 16, 2011 at 8:38 AM, Gareth McMullin <ga...@bl...> wrote: > Ok, there seems to be a lurking bug in the USB code. You aren't the > first person to have this problem. I unfortunately can't reproduce the > problem with either of the two hosts I have available. I've found the problem: just tried building with summon-arm-toolchain, and I observe the same problem. The build_config_descriptor() function uses memcpy() to contruct the configuration descriptor, on entry to memcpy an invalid instruction is encountered and the target is found in blocking_handler(). No further USB requests are handled. It seems that summon-arm-toolchain is linking in an ARM mode memcpy instead of thumb. This can be solved by adding -mthumb to the linker options. I've attached a patch to the generic makefile, which just added the full CFLAGS to the linker command line. It solved the problem and should be safe. I've also removed the "-Wl,--gc-sections", and changed options to "-O0 -g3". The options in git make the examples very hard to debug, and I think this may create a barrier to newbies trying out the library. Especially for an example, we can give up some size to make things easier. Regards, Gareth -- Black Sphere Technologies Ltd. Web: www.blacksphere.co.nz Mobile: +64 27 777 2182 Tel: +64 9 478 8885 Skype: gareth.mcmullin LinkedIn: http://nz.linkedin.com/in/gsmcmullin |
From: Gareth M. <ga...@bl...> - 2011-02-15 19:38:50
|
Ok, there seems to be a lurking bug in the USB code. You aren't the first person to have this problem. I unfortunately can't reproduce the problem with either of the two hosts I have available. If you can take a capture of the usb activity with Wireshark, I'll have a look at it to see what I can find. Regards, Gareth On Wed, Feb 16, 2011 at 1:31 AM, gwenhael.goavec <gwe...@fe...> wrote: > Hi, > > I have a custom board based on STM32F103 microcontroller. > My toolchain is created thanks to summon-arm-toolchain script. > I work with linux. > > I wish to use the usb device. In a first time, I have used > examples shipped with library. > > With cdcacm or usbhid (maybe with others too), I have errors when I plug the usb > cable. > dmesg exemple for usb_hid.elf: > > [167604.696192] usb 3-1: new full speed USB device using uhci_hcd and address 21 > [167609.843315] usb 3-1: unable to read config index 0 descriptor/start: -110 > [167609.843326] usb 3-1: chopping to 0 config(s) > [167614.845496] usb 3-1: string descriptor 0 read error: -71 > [167614.845519] usb 3-1: New USB device found, idVendor=0483, idProduct=5710 > [167614.845531] usb 3-1: New USB device strings: Mfr=1, Product=2, > SerialNumber=3 [167614.845879] usb 3-1: no configuration chosen from 0 choices > . > lsusb shows the good informations about VendorId and ProductId. > On a other side lsusb -v show bNumConfigurations : 0 > > Bus 003 Device 012: ID 0483:5710 SGS Thomson Microelectronics > Device Descriptor: > bLength 18 > bDescriptorType 1 > bcdUSB 2.00 > bDeviceClass 0 (Defined at Interface level) > bDeviceSubClass 0 > bDeviceProtocol 0 > bMaxPacketSize0 64 > idVendor 0x0483 SGS Thomson Microelectronics > idProduct 0x5710 > bcdDevice 2.00 > iManufacturer 1 > iProduct 2 > iSerial 3 > bNumConfigurations 0 > > To test if problem is relative to my board or an other problem, I have used > prebuild usbmouse demo available on olimex's website. With this example, I have > the good result. > > I have no idea of reasons of this problem, maybe my arm-none-eabi-gcc-4.5.1 > If someone has an idea to correct this issue. > > Thank you very much. > > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > _______________________________________________ > libopenstm32-devel mailing list > lib...@li... > https://lists.sourceforge.net/lists/listinfo/libopenstm32-devel > -- Black Sphere Technologies Ltd. Web: www.blacksphere.co.nz Mobile: +64 27 777 2182 Tel: +64 9 478 8885 Skype: gareth.mcmullin LinkedIn: http://nz.linkedin.com/in/gsmcmullin |
From: gwenhael.goavec <gwe...@fe...> - 2011-02-15 13:01:50
|
Hi, I have a custom board based on STM32F103 microcontroller. My toolchain is created thanks to summon-arm-toolchain script. I work with linux. I wish to use the usb device. In a first time, I have used examples shipped with library. With cdcacm or usbhid (maybe with others too), I have errors when I plug the usb cable. dmesg exemple for usb_hid.elf: [167604.696192] usb 3-1: new full speed USB device using uhci_hcd and address 21 [167609.843315] usb 3-1: unable to read config index 0 descriptor/start: -110 [167609.843326] usb 3-1: chopping to 0 config(s) [167614.845496] usb 3-1: string descriptor 0 read error: -71 [167614.845519] usb 3-1: New USB device found, idVendor=0483, idProduct=5710 [167614.845531] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [167614.845879] usb 3-1: no configuration chosen from 0 choices . lsusb shows the good informations about VendorId and ProductId. On a other side lsusb -v show bNumConfigurations : 0 Bus 003 Device 012: ID 0483:5710 SGS Thomson Microelectronics Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x0483 SGS Thomson Microelectronics idProduct 0x5710 bcdDevice 2.00 iManufacturer 1 iProduct 2 iSerial 3 bNumConfigurations 0 To test if problem is relative to my board or an other problem, I have used prebuild usbmouse demo available on olimex's website. With this example, I have the good result. I have no idea of reasons of this problem, maybe my arm-none-eabi-gcc-4.5.1 If someone has an idea to correct this issue. Thank you very much. |
From: Uwe H. <uw...@he...> - 2011-02-09 01:49:52
|
On Tue, Feb 01, 2011 at 07:35:03AM -0600, Marko Kraljevic wrote: > I've attached a patch consisting of: > Modify gpio.c so that gpio_toggle() supports multiple gpios. Merged, thanks. > Modify rcc.c to provide rcc_clock_setup_in_hse_8mhz_out_24mhz(), as > 24MHz is the maximum speed of the chip on the stm32 discovery board. Merged, too. > Added directory of examples, tested on stm32 discovery, just > modifications of: > button, miniblink, fancyblink, usart, and rtc. Merged, too, with some minor fixups. Haven't tested the examples on hardware yet, but will probably do so later. Just to make sure -- you have the ST STM32VLDISCOVERY from http://www.st.com/internet/evalboard/product/250863.jsp, correct? Thanks, Uwe. -- http://hermann-uwe.de | http://sigrok.org http://randomprojects.org | http://unmaintained-free-software.org |
From: Gareth M. <ga...@bl...> - 2011-02-09 01:37:04
|
On Wed, Feb 9, 2011 at 2:21 PM, Uwe Hermann <uw...@he...> wrote: > It seems you forgot to add the headers (e.g. gpio.h) though? Sorry. They're added now. - Gareth -- Black Sphere Technologies Ltd. Web: www.blacksphere.co.nz Mobile: +64 27 777 2182 Tel: +64 9 478 8885 Skype: gareth.mcmullin LinkedIn: http://nz.linkedin.com/in/gsmcmullin |