Selecting an alternate function

[brberie]

Posted on November 11, 2012 at 23:46

Reading UM0033, page 138, figure 14.

Sorry, can not exactly understand it. For example,  I want to connect C.8 to CAN1_TX and C.9 to CAN1_RX. I see AF9 (CAN1/CAN2, TIM12..14). and need to use GPIOC_AFRH(LSB)

GPIOC->AFR[1].&= ~0x0000000F; // clr

GPIOC->AFR[1].|=  0x00000009; // AF9

But how do I know that it is CAN1, not the other alternatives and where is CAN1_TX and CAN1_RX?

Thanks

#alternate-function-mapping

[Tesla DeLorean]

Posted on November 12, 2012 at 02:46

What part are you using? No CAN bus uses/routes to PC8/PC9 on the STM32F4, or the F2 as I recall. Do you mean RM0033 for the STM32F2? You need to also look at the Data Manuals for the specific part being used, as these have the pin lists. Table 7 in the Reference Manual also breaks down pin/routing options.

PB8/PB9 can be used with CAN1, there are two pins needing AF routing

GPIOB->AFR[1] &= ~0x000000FF; // clr

GPIOB->AFR[1] |=  0x00000099; // AF9

[brberie]

Posted on November 12, 2012 at 03:14

I'm learning how to use STM32F2. Yes, I'm reading RM0033 Doc ID 15403 Rev 5 from Nov 2012. I don't really care about CAN or any specific peripheral, but failing to understand how to configure/multiplex pins via GPIOx_AFR.

Table 7 in the document above has nothing to do with my confusion. I'd greatly appreciate if you can point me to any other document which may help me with this challenge.

PS Doc ID 15818 Rev 9 is required to understand RM0033. I'm very disappointed with such way of documenting ...

Thank you for the clue.

Thanks.

[brberie]

Posted on November 12, 2012 at 03:42

Doc ID 15818 Rev 9 is required to understand RM0033. I'm very disappointed with such way of documenting ...

Thank you for the clue.

[Tesla DeLorean]

Posted on November 12, 2012 at 03:53

For the F2 perhaps Table 8 here ''Alternate Function Mapping''

http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00237391.pdf

Part specific data manuals, family series reference manuals. Not all the part# share the same die or bond-out/package options.

[waclawek.jan]

Posted on November 12, 2012 at 06:24

IMHO, Michurin is right and this info belongs to the user manual rather than the datasheet.

> Part specific data manuals, family series reference manuals.

> Not all the part# share the same die or bond-out/package options.

Yes; but this has to do with the GPIO-to-AF mapping, which appears to be the same across family, rather than with pinout, or am I wrong?

JW

[frankmeyer9]

Posted on November 12, 2012 at 10:38

IMHO, Michurin is right and this info belongs to the user manual rather than the datasheet.

 

You should less read NXP documentations ... ;)

But honestly,  this separation in ref. manual and datasheet is somehow arbitrary.

Several uC vendors put everthing in ONE datasheet. TI would be one example from the ARM Cortex camp...

[brberie]

Posted on November 12, 2012 at 13:14

Where to put what is a matter of publishers preferences, but not, at least, to refer to each other is a very bad taste!

[Tesla DeLorean]

Posted on November 12, 2012 at 16:06

IMHO, Michurin is right and this info belongs to the user manual rather than the datasheet.

 

 

> Part specific data manuals, family series reference manuals.

 

> Not all the part# share the same die or bond-out/package options.

 

 

Yes; but this has to do with the GPIO-to-AF mapping, which appears to be the same across family, rather than with pinout, or am I wrong?

There isn't a user manual, and the documentation is not separated in a totally unreasonable fashion. Perhaps they could cross reference better, but that's real hard to keep in sync around multiple releases, or without revising multiple documents for localized changes. For most, there are two manuals (data/reference), a third covering the flash programming, and you could use a reference for the core. Like dumping all source in a single file there are plenty of reasons to split it up. How ST demarcated the content is perhaps arguable, but it's certainly a lot better than much of the part documentation I've worked with over the years. The web site, and where documentation can be found does need a lot of work.

On low pin count devices some pins have duality of use, there are also timer pins described separately, but are connected together. GPIO pins that don't escape the package can still be muxed via the AF fabric, and can be routed internally for creative purposes. You're not wrong, my point just had a broader target.