cancel
Showing results for 
Search instead for 
Did you mean: 

Does stm32f105xc.h work for STM32F105R8T6? Does STM32F105R8T6 have a "USB_IRQn"?

temp2010
Senior

New to STM32. Decades old to MCUs. Trying to adapt individual features from existing STM32F042C6T6 project to new STM32F105R8T6 project.

1) Old project included stm32f042x6.h. My new project includes stm32f105xc.h. Does this .h work for STM32F105R8T6? The "xc" doesn't match the "R8T6".

2) Old project had usb callback that references USB_IRQn. It's defined in stm32f042x6.h but not in stm32f105xc.h. Thus my confusion. Advice?

3 REPLIES 3

The STM32F105 are all the same chip, the individual models differ only in packaging and how much of the RAM and FLASH is tested (or maybe disabled). As the header file does not make any reference to RAM size nor pinout, the same header can be used for all 'F105.

There are two entirely different USB modules in the various STM32 models/families - the simpler, device only, and a comples host+device+OTG. The 'F042 implements the former, the 'F105 implements the latter. They are completely different, and the code is not portable.

From the rather old and quirky 'F1 family the 'F103 implements the simpler device-only USB and there should be some level of compatibility with the USB in 'F042, although there may be differences in the minute details (e.g. the 'F103 does not have an integrated DP pullup).

JW

temp2010
Senior

JW,

Thanks very much for this info. It is consistent with the alternative path I have tried since my post. Perhaps you would be so kind as to comment on this...

Seeing that usbd_conf.c referencing USB_IRQn was dated 2014, I looked at it closer. The top of it mentioned "cube". I though to myself "I downloaded a brand new cube for this processor". I figured, "let me upgrade all this to NEW code." I looked. I found a "CDC_Standalone" example project. Just now, I got that to build successfully. Of course, it appears to be for "STM3210C_EVAL" board. I am next going to try and upgrade THIS example to my own board. Then I'll work forward from this platform.

Be aware that the "new STM32F105R8T6" project from my original post did nothing so far but write "hello world\n" out a serial port. Well, the "CDC_Standalone" example says it forwards info between a USB port and a UART. (Don't get confused on the USB host and virtual serial port. The UART mentioned should be real physical serial port.) That USB<->Serial is extremely close to the point I would have been with my original direction. So with this new direction, if I can simply get the "CDC_Standalone" example running on my board, then I'll be at the desired point. That point will be working USB (CDC) and serial port, regardless of what higher level (or callback code) is doing. From that point, I can go take the "application level" code from the old STM32F042C6T6 project mentioned, skipping over the lower level USB stuff. This should get me where I need to be, with the "application" now working on my new hardware.

JW, do you think I'll get to my destination?!

FYI, the existing STM32F042C6T6 project essential relayed CAN bus data to/from USB. The point above will relay UART data to/from USB. I'll probably find myself next looking for a *new* CAN bus example, get it going, and then merge that CAN bus low level stuff into my project. At this subsequent point, I should have a project with working USB, UART, and CAN. I'll re-plumb the top level application (guided by the existing STM32F042C6T6 project) to convert the USB<->UART relay into a USB<->CAN relay, with the UART doing only status and diagnostics (my overall intent for the otherwise superfluous UART).

Sounds like a plan, if you can live with whatever Cube will offer you.

JW