LPC15xx: PINASSIGN6 last field (USB_CONNECT) missing in manual?

[volkeroth]

I wasted some hours yesterday trying to understand why Pin0.0 on a LPC1549 was behaving as an output though it was configured as input and not assigned to any function described in the manual through PINASSIGNx.

After I could rule out a HW defect or obvious configuration problem, I checked all involved registers in the peripheral view of LPCXpresso while debugging. I noticed that LPCXPresso shows four fields for PINASSIGN6 while the manual describes only three and the last missing one (31..24) is just named "reserved". However, in contrary to PINASSIGN15, writing a 0 (or not writing 0xff) to bit 31..24 of PINASSIGN6 actually assigns Pin0.0 to some output function.

According to LPCXpresso this function is USB_CONNECT - which is mentioned only twice in the manual, but not in a way that would make clear how to assign it to a pin.

So I figure the description of PINASSIGN6 is missing the field for USB_CONNECT. Shouldn't this be corrected in the manual? I'm using Rev. 1.1 (March 2014) which seems to be the newest one...

As a side note: the PINASSIGNx registers all have a reset value of 0xff defined for their configuration fields. My yesterday's investigation seems to show that this is not really true. Maybe it's a power on reset initialization, but the values there seem to have survived several warm resets and reprogramming with a simple pin test software which didn't write to the PINASSIGNx registers.

[volkeroth]

Thanks for the reply. Still, if bits 31 to 24 in PINASSIGN6 are set to 0, this makes P0.0 an output. So if it's not USB_CONNECT, there is some other output functionality configured by this field. It's clearly not a reserved field in the sense that writing some pin identifier there will have no obvious effect. As I said, I just stumbled over this because P0.0 was effectively an output even though I hadn't configured it as such. And only after writing 0xff to the according field in PINASSIGN6 , P0.0 behaved as expected.

[ckphua]

For Reserved field, it should NOT be written and keep as 0xFF. If you had assigned Pin0_0 to PINASSIGN15 earlier and you now write 0x0 to PINASSIGN6 bit 31 to 24, you are over-writing PINASSIGN15 function with ASSIGN6 b31:24 onto Pin 0_0.

[volkeroth]

I had not deliberately assigned P0.0 to any function through PINASSIGNx because I wanted to use it as input. This happened by accident because of the somewhat lacking description of PINASSIGN6 in the manual.

I just mentioned PINASSIGN15 to emphasize that the reserved fields there are actually non-functional as you would expect hem to be. I.e. writing a 0 there doesn't assign Pin0.0 to any undocumented special function.

However, writing a number in the reserved field of PINASSIGN6 does assign a pin to some output function.

So at least there should be a hint like "Reserved: must be only written with 0xff".

Please note that reserved bits that must not be overwritten with 0 are generally considered as bad style and dangerous. Thoughtful developers will use AND masks to avoid writing ones into reserved fields, but the need to consider a specific reset value of each and every reserved bit is an immense effort for a developer and will usually end with unexpected behavior that is hard to track. At least such a behavior should be clearly documented.

Generally, I would hope that the manuals would be updated more frequently. There are lots of mistakes and vague descriptions in the LPC15xx user manual and it seems weird that nobody cared to improve it for more than two years.

[ckphua]

The USB_CONNECT (aka SoftConnect) function do not need a pin (refer to Fig 59 USB Block Diagram of UM). During the implementation, the PINASSIGN6 empty slot on bit 31 to 24 was used for testing/verification. Given it is not necessary to have USB_CONNECT on a pin, this was dropped from the UM and classified as Reserved. Unfortunately the LPCXpresso got an earlier test version of our register description, which resulted in the extra slot. 

The observation with some PINASSIGNx registers not Reset to 0xFF on warm reset is correct as it was done deliberately to preserve the setting till a POR or BOD reset. There is a statement about this on Page 72 UM section 3.7.1 Reset