Mistake in reference manual, SDIO response registers, 4 or 5 ?

[briand.myers9]

Posted on February 19, 2009 at 22:22

Mistake in reference manual, SDIO response registers, 4 or 5 ?

[briand.myers9]

Posted on May 17, 2011 at 13:03

Hello forum !

I've found a mistake in this reference manual : http://www.st.com/stonline/products/literature/rm/13902.pdf Section 19.9.6 can't seem to decide if there are 4 or 5 SDIO response registers. 0 through 4, or 1 through 4 ? I'm pretty sure there are really only 4; however, my compiler vendor (Rowley Crossworks) has been led astray by this mistake, and has defined 5 registers instead of 4. I've submitted a bug report to them. Also a concern to me, is that the STM FWLib defines a lot of identifiers which conflict with Rowley's supplied header file, implying to me that I must NOT use their header if I want to use FWLib, and vice-versa. Ick. Has anyone else run across this type of problem, and if so, any advice? We're starting our development using this processor, so we need to decide one way or the other soon. The FWLib looks good because of all the example code supplied which depends on it, but the Rowley header has better detail - masks definitions, etc. So we're undecided so far. thanks in advance, Brian

[jj]

Posted on May 17, 2011 at 13:03

Hi Brian,

No specifics (sorry) but please be sure that you are using newest versions of STM FwLib & your compiler. We use IAR and appear to enjoy much better ST -> compiler ''match.'' You may want to bring your header file slowly - function by function - into compatibility with the FWLib...

[briand.myers9]

Posted on May 17, 2011 at 13:03

Thanks for the response. Yes, we're using the latest Cortex support package from Rowley, and latest FWLib.

Found out something I didn't know from this problem, though. In our configuration, the GCC compiler apparently does not display any warnings found in ''system headers'', which the Rowley header is, and the FWLib header is not (regardless of -Wall). So, the ''identifier re-defined'' warnings I would have expected to get, I never saw, because the Rowley header was included *after* the FWLib header. Fortunately, the FWLib assertions showed the problem at run-time immediately. At this stage we're going to just remove the Rowley header, and use the FWLib one instead, and see how things go.