Help interpreting USB OTG docs for stm32f1xx

[ashibakov]

Posted on September 05, 2012 at 16:30

Hi all!

The software design process we use requires that every piece of code is heavily tagged with references to the original programming manuals. Sometimes these tags are added during code reviews, etc. The question I have is therefore a bit unusual: Where in the reference manual can one find any information on how to use the data FIFOs? The docs use the terms `push to FIFO' and `pop FIFO' but there are no definitions of what that means. The register map gives an `address range' for the FIFO with an annotation `push/pop to this region'. We have written the code by looking up the fw library supplied by ST (we cannot use the library for a number of reasons, one being it does not meet our code standards) so the the way to `push to FIFO' is simply to write to the bottom address in the `address range' mentioned in the manual (`address range' should really be called `offset range') but the manual is mum about whether writing to any address in the range will work or such uses are illegal, etc. So is there a more detailed description of the FIFO somewhere else? The whole section on USB OTG is pretty much useless for writing code: one has to look up the code examples from ST which slows the process down somewhat and interferes with our design flow. Thanks

[Tesla DeLorean]

Posted on September 05, 2012 at 18:28

As a commercial customer you'd likely want to interface with your FAE and ST reps to gets some definitive answers, and push into the design group.

This is a user forum, so at best you'll get empirical evidence or experiences, more rigorous documentation may well take an NDA.

[ashibakov]

Posted on September 05, 2012 at 20:04

We have considered this but our volume does not justify that kind of attention from ST (we mostly design `one-off' hardware). NDAs are out of the question for a number of reasons, some of them have nothing to do with design.

Pragmatically speaking, it is not a question of having RTL type specs for the chip, it is just a matter of having precise language in the documentation to refer to. We have had problems with poor docs before and there are provisions in the process to deal with that just not for a microcontroller. In any case, stm32 is a new target for us (even though we have a lot of experience with cortex-M3 design) and lack of proper documentation is just one of the factors. I just hoped someone would point out the language I missed. Any help is appreciated and thanks for the reply. Alex

[Tesla DeLorean]

Posted on September 05, 2012 at 20:47

I'm a ''trust-but-verify'' kind of guy, but you seem to be erecting hurdles to getting to the answers you're looking for.

Table 202 is indicative that the whole region (0x1000 .. 0x1FFC, etc) is mapped on the AHB (ie closer to the processor than the APBx), and the operation of the FIFO is agnostic to the low order bits. This would permit you to copy 32-bit words within this space, and each would go into the FIFO. You could validate this by writing backward through this space, and confirm it functions as it did before. This would be the equivalent to reading a stream from a NAND device.

[ashibakov]

Posted on September 06, 2012 at 00:39

Thanks for the reply

>I'm a ''trust-but-verify'' kind of guy, but you seem to be erecting >hurdles to getting to the answers you're looking for. Just to reiterate, it is not a question of finishing the design---it has already been verified, and documented, this is just something that came up during code reviews. >Table 202 is indicative that the whole region (0x1000 .. 0x1FFC, etc) >is mapped on the AHB (ie closer to the processor than the APBx), and >the operation of the FIFO is agnostic to the low order bits. This would >permit you to copy 32-bit words within this space, and each would go >into the FIFO. You could validate this by writing backward through >this space, and confirm it functions as it did before. This would be the >equivalent to reading a stream from a NAND device. It would be nice to have something even this vague in the reference manual. `Indicative' is not `definitive', though. Other implementations use a single register as a point of access for the FIFO (Stellaris is one, the FIFOs are mapped to AHB, as well, lower bits are significant). We have been burnt in the past by `experiment and implement' strategy when the next part number changed some poorly documented behavior (not an ST part). The question was raised whether another part number (or even the next revision of the same part) will change the mapping of the FIFOs, say map different FIFOs to the different regions in the 0x01000--0x01FFFC offset range. 30 year+ lifecycle for the hardware does imply some birthing pains, unfortunately. Thanks again for the reply.

[Tesla DeLorean]

Posted on September 06, 2012 at 01:17

You need to escalate your request for clear and precise documentation through a contact at ST, they have approaching zero participation in the forum.

[ashibakov]

Posted on September 06, 2012 at 02:06

I was afraid that much was true. I will give them a call and see what happens. I appreciate the help.

Alex