cancel
Showing results for 
Search instead for 
Did you mean: 

Undue difficulty in alt function mapping using current docs

lanchon
Associate II
Posted on February 21, 2008 at 17:36

Undue difficulty in alt function mapping using current docs

7 REPLIES 7
jas
Associate II
Posted on May 17, 2011 at 12:22

Lanchon,

I agree, assigning I/O, alternate functions & remapping is like a game of chess.

I am currently using the keil config wizzard to help me, but I don't think it is complete, yet.

There are many registers to configure and they must be done in the correct order.

The ST CAPS utility for STR912 devices was good to work with, maybe they can do a CAPS for STM32 Cortex ?

I still like this cortex chip.

16-32micros
Associate III
Posted on May 17, 2011 at 12:22

Dear All,

We appreciate a lot your remarks about Alternate Function mapping, I will send all to our applications engineers to make them more clear in documentation and may be have something like CAPS or Keil and independant from the tool-chains. Thank you again 😉

Cheers, STOne-32.

lanchon
Associate II
Posted on May 17, 2011 at 12:22

Thanks STOne32, you're always there to help. In the meantime, could you risk an answer to these questions?

-What happens when more than one output signal of different peripherals that share the same pin are enabled?

-Can all output signals of all peripherals be individually disabled?

Thanks again!

lanchon
Associate II
Posted on May 17, 2011 at 12:22

Hi all,

Working back from the pins into the STM32, first you find the GPIO block which can select, with pin granularity, either GPIO function or alternate function. Then the AFIO block can shuffle the signals around with AF granularity. Both these blocks are described neatly in chapter 5 of the ref manual.

Then come the problems, documentation is very sketchy here on. Several signals of different AFs can share the same pin, and apparently there's no info whatsoever regarding how this sharing is done.

The absence of this info, coupled with the fact that many AF output signals have some kind of enable bit, leads one to suppose this: if only one AF output from a pin sharing set is enabled, you'll get that output.

But many questions remain:

-What happens when more than one AF output is enabled? Is there some sort of priority scheme? Or is there contention on a shared bus raising all sorts of concerns?

-What happens when no AF output is enabled or when some AF signals of the share set are inputs?

And the most important question by far:

-Which pins of each AF can be disabled or at least set as inputs at will?

I couldn't find a centralized source for answering this last question and IMHO this is very bad news. Apparently you have to study each peripheral in detail to know which signals can be disabled (or set as inputs). So you have to become an expert in *ALL* peripherals you intend to use, to be able to try and find an AF set plus AFIO config that will suit your needs, BEFORE staring to draw the schematic.

Well this is my view: finding an AF set plus AFIO config is difficult enough in complex designs, but on top forcing designers to become experts in all peripherals is completely ridiculous!

Case in point: I want to reserve a USART and two pins (TX/RX) for an eventual RS-232 configuration port, that I doubt will ever be implemented. (Even so, I must be certain that it's going to be possible to implement it later if needed.) Now, the USART shares pins CK, CTS and RTS with a timer. Am I supposed to read the whole chapter on the USARTs to know if these pins can be disabled? Of course I could just ASSUME that this can be done, but make enough of these assumptions and one will fail.

So, questions:

-Am I being dumb and this info is readily available?

-Has someone compiled this info for all or some peripherals?

-Can all AF signals be individually disabled? / Has someone seen AF signals that can't be disabled with signal granularity?

For ST staff:

Unless a broad generalization is applicable, please consider compiling tables of the possible signal usage combinations for all peripheral and release it informally ASAP. Then centralize this info with a description of the signal sharing mechanism into chapter 5 of the ref manual. (Also consider duplicating the signal usage table for each peripheral at the start of its corresponding chapter.) Those that feel the same way about this are welcome to second this petition.

Thanks for reading this rant and for your help.

Cheers!

16-32micros
Associate III
Posted on May 17, 2011 at 12:22

Hi Edison,

How are you doing ? 🙂 It is long time that you haven't posted there. Thank you for your answer, It seems that I have missed this one, I will add some additional details :

Q1) What happens when more than one output signal of different peripherals that share the same pin are enabled? like USB/CAN , USART RTS etc...

A1) This is an OR between pins, if one AFO is stuck at one and the other toggling the result will be an output stuck at 1. This is the reason why only one peripheral alternate must be enabled at a time.

Q2) Can all output signals of all peripherals be individually disabled ?

A2) Internally, There are several behaviors : Some peripherals (e.g. timer) could en/dis-able the output internally, Others use the clock enable to disable the alternates functions (e.g. spi, i2c, ...). From an user/application point of view this is more or less the same.

Hope this is more clear 🙂

Cheers, STOne-32

tomas23
Associate II
Posted on May 17, 2011 at 12:22

The outputs of enabled functions are OR-ed (combined) together. Cannot tell if all outputs specifically can be disabled, but you can keep all peripherals in reset separately. However lot of outputs like for UART, SPI, timers etc. can be disabled.

lanchon
Associate II
Posted on May 17, 2011 at 12:22

@edison, ST,

thank you!