I’ve looked at the SRM and the Bone schematic and I’m still a bit unsure as to where I2C2 needs to be assigned on the expansion header by the pinmux such that the Bone always can read the cape EEPROMs. Not like the cape EEPROMs can just guess where to attach themselves but there’s at least a few places that the pinmux can put I2C2 on the expansion headers. Best I can tell I2C2 should always be assigned to P9_19 (I2C2_SCL) and P9_20 (I2C2_SDA) but I don’t see anything explicit and definitive on that. Maybe I missed it somewhere. Can someone confirm that the cape EEPROMS need to be connected to P9_19 and P9_20 or should they connect somewhere else to function?
Thanks,
Eric
That is why the signals are called I2C2_SCL and I2C2_SDA. That is where the I2C2 bus must be located and therefore the Cape must connect the EEPROM to these pins in order to fucntion…
Gerald
Gerald,
Thanks for the quick reply. Being a bit new at this it’s helpful to verify that I got it right as sending the wrong artwork off to the boardhouse gets expensive really fast. It might help those of us a bit newer at this if there was an explicit reference in the SRM to which pins MUST remain unchanged in their function to meet spec. (P9_19 & P9_20 being 2 of them but are there any others…)
Thanks,
Eric
I have added the verbage to the updated TRM saying just that. It says where to put it now, just not listed were the pin numbers.
Gerald
Gerald,
Did you mean SRM? What I know of as being referred to as the TRM is essentially the comprehensive data sheet for the processor itself.
Eric
Should Table 15 LOC 98-99 be prefilled in so as to prevent shootng self in foot? Reassigning the pinmux via those addresses seems like a good way to assure that the config EEPROMs that contain those addresses are no longer readable. This would not be good. Having those fields in the table prefilled with a note reminding users not to change what is there at risk of shooting self in foot would be useful.
Eric
Sorry, Table 15 of the bone SRM…
Eric
Yes, I meant SRM. I had a meeting starting and I was trying to answer before I got taken away!
My intent was at UBoot all of the pin muxes would be set as per the labeling on the schematic. However, with the Capes they could actually cause some conflicts, so the long term plan would be to set I2C2, read the EEPROMs, and then set the pin muxing based on what they required instead of a default setting. UBoot does set this normally. If someone wants to come back and write over it and shoot themsleves in the foot, there is not much we can do about it. They just need to read the SRM, and follow it and not start shooting everywhere.
Gerald