cancel
Showing results for 
Search instead for 
Did you mean: 

OTYPER Reset value in Ref Manual wrong?

flyer31
Senior
Posted on January 27, 2012 at 11:54

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?).

4 REPLIES 4
flyer31
Senior
Posted on January 27, 2012 at 12:17

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?

flyer31
Senior
Posted on January 27, 2012 at 12:28

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.

shannon2
Associate II
Posted on January 28, 2012 at 22:26

Is there a reason the validity of the reset value is important to you?

flyer31
Senior
Posted on January 28, 2012 at 23:10

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).