RE: [Bug 1001550] STM32 F2 and STM3220G-EVAL / STM3240G-EVAL contribution from eCosCentric

["Christophe Coutand" <ccoutand at stmi dot com>]

Thanks,

Also STM32 variant has redefined the CYGHWR_HAL_STM32_RCC_APBxENx definitions from bit position to index so additional changes to the USB driver or other STM32 drivers might be required.

Christophe

-----Original Message-----
From: ecos-patches-owner@ecos.sourceware.org [mailto:ecos-patches-owner@ecos.sourceware.org] On Behalf Of bugzilla-daemon@bugs.ecos.sourceware.org
Sent: 3. april 2012 20:46
To: ecos-patches@ecos.sourceware.org
Subject: [Bug 1001550] STM32 F2 and STM3220G-EVAL / STM3240G-EVAL contribution from eCosCentric

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001550

--- Comment #19 from Jonathan Larmour <jifl@ecoscentric.com> 2012-04-03 19:46:08 BST ---
(In reply to comment #18)
> Hi Jonathan,
> 
> Could you check STM32 USB driver -> CYGHWR_HAL_STM32_RCC_APB1ENR_CAN

Hoho, I wouldn't have expected to find a CAN-related define in the USB driver!

Trivially fixed with CYGHWR_HAL_STM32_RCC_APB1ENR_CAN ->
CYGHWR_HAL_STM32_RCC_APB1ENR_CAN1 which I'll commit now.

Arguably, someone with a better ability to test USB may want to consider using
the clock descriptors and CYGHWR_HAL_STM32_CLOCK_ENABLE/DISABLE macros,
possibly as well as the new superior GPIO pin interface (even though the old
interface remains).

Although on the other hand, it looks like this form of USB device is a dead-end
- as far as I can tell, ST have moved towards a completely different OTG
peripheral instead with totally different interface, not just on F2/F4, but
also on F1 connectivity line parts.

Jifl

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.