2012-01-27 02:54 AM
In Ref. Manual 6.4.11 Table 18, for the registers GPIOx_OTYPER a reset value of 0x4444 is specified, but I think this is an error - should be 0x0000? (as specified in 6.4.2 at the register description?).
2012-01-27 03:17 AM
Either my Keil Debugger is showing some stupid Watch window results on Reset, or the Reference manual seems to show quite stupid information - at least for the Debug Pin GPIO register settings.
For MODER, OTYPER, OSPEEDR, PUPDR,LCKR the values are the following: (Reference manual from Table 18, 6.4.11): Keil GPIOA: 0x00000000, 0xA8000000,0xA8000000,0xA8000000,0xA8000000 Ref GPIOA: 0xA8000000, 0x00004444, 0x00000000,0x68000000,0x00000000 Keil GPIOB: 0x00000280, 0x00000280,0x00000280,0x00000280,0x00000280 Ref GPIOB: 0x00000280, 0x00004444, 0x000000C0,0x00000100,0x00000000 Besides these discrepancies, it is really puzzling that the Watch windows shows values as 0xA8000000 for the OTYPER and LCKR - these are 16 bit registers with upper 16 bits ''Reserved'' - as I understand it, the upper 16 bits always should read zero, so 0xA8000000 is some impossible result for these 2 types of registers. Further it is strange, that the LOCKR bits are set already for the Debug pins in Port A + B? I checked this at the reset point in dissassembly window, directly after pressing reset (so BEFORE the SystemInit function is called). Anyone can help here?2012-01-27 03:28 AM
For PORTA even AFR[0] and AFR[1] is 0xA8000000 on reset (and for PORTB it shows 0x00000280) - which really is impossible (Debug would not work then, as Debug need Alternate function 0 for these pins). So I think maybe the Watch window cannot show these bits correctly fo rthe debug port A?
I tried to look at memory location 0x40020000 (which is the base address of GPIOA) in the memory window, but this does not work. Keil shows some error message ''Internal command error'', and all zero's.2012-01-28 01:26 PM
Is there a reason the validity of the reset value is important to you?
2012-01-28 02:10 PM
No, not really, I am just starting with a ''start from some early point'' development - I usually specify all ports at the beginning in a ''InitPorts'' function, and I was a bit disturbed concerning the discrepancies in the RefManual. At first I was concerned, that the OpenDrain functionality might be important for some type of signals (especially e. g. 5V-tolerancy...), but I think it is just an error in the RefManual - I do not see any sense why any output should switch to OpenDrain on reset.
The lock bits would be interesting for me only, if I would run out of pins, in such case I would perhaps try to use the JTAG pins for my process. But currently I have no pin-count problems (it would be interesting to get this processor in a small QFN32 or QFN48 package for some applications, in such a case this situation would change I think).