timtianyang 0 Posted August 10, 2013 Share Posted August 10, 2013 Hi, As I was trying to enable SPI0 with LCD4 cape at the same time, I got an error says pin conflict on GPIO0_3(P9_21) with LCD4 cape. I noticed that in the latest image Angstrom730 image the device tree for LCD4-A1 has GPIO0_3 assigned as exclusive use which is not in the schematic on wiki support website. Is this an error or am I missing something? https://github.com/CircuitCo/BeagleBone-LCD4-RevA1/blob/master/BeagleBone-LCD4-RevA1-schematic.pdf?raw=true version = "00A1"; /* state the resources this cape uses */ exclusive-use = /* the pin header uses */ "P8.45", /* lcd: lcd_data0 */ "P8.46", /* lcd: lcd_data1 */ "P8.43", /* lcd: lcd_data2 */ "P8.44", /* lcd: lcd_data3 */ "P8.41", /* lcd: lcd_data4 */ "P8.42", /* lcd: lcd_data5 */ "P8.39", /* lcd: lcd_data6 */ "P8.40", /* lcd: lcd_data7 */ "P8.37", /* lcd: lcd_data8 */ "P8.38", /* lcd: lcd_data9 */ "P8.36", /* lcd: lcd_data10 */ "P8.34", /* lcd: lcd_data11 */ "P8.35", /* lcd: lcd_data12 */ "P8.33", /* lcd: lcd_data13 */ "P8.31", /* lcd: lcd_data14 */ "P8.32", /* lcd: lcd_data15 */ "P8.27", /* lcd: lcd_vsync */ "P8.29", /* lcd: lcd_hsync */ "P8.28", /* lcd: lcd_pclk */ "P8.30", /* lcd: lcd_ac_bias_en */ "P9.27", /* lcd: gpio3_19 */ "P9.12", /* led: gpio1_28 */ "P9.14", /* pwm: ehrpwm1a */ "P9.15", /* keys: gpio1_16 */ "P9.23", /* keys: gpio1_17 */ "P9.16", /* keys: gpio1_19 */ "P9.21", /* keys: gpio0_3 */ /* the hardware IP uses */ "gpio3_19", "gpio1_28", "gpio1_16", "gpio1_17", "gpio1_19", "gpio0_3", "lcd", "ehrpwm1a"; Tim Quote Link to post Share on other sites
spirilis 1,265 Posted August 14, 2013 Share Posted August 14, 2013 Hi there- Just decided to take a look. According to the LCD4 schematic, it uses P9_21 UART2_TXD but all it does is break it out to another header (that's not populated? says DNI in the schematic). Don't know what the point of that is, but I don't own one of these either and the pics on the site don't give details. http://beagleboardtoys.info/index.php?title=BeagleBone_LCD4 - Schematic (PDF) link down at the bottom is what I'm going by here. If there's some way you could override it, build a new devicetree file for that cape (find its .dts source first), it may be possible to ignore this conflict since I'd imagine it's not actually used. But you should definitely verify physically that it isn't used for anything. Probe it with a multimeter, or preferably oscilloscope and/or logic analyzer to validate that pin isn't being tweaked by the cape or software onboard. edit: Also, just email CircuitCo and ask. I think they may have designed the cape. They should have the devicetree source file available and/or can advise on how to resolve this issue. bluehash 1 Quote Link to post Share on other sites
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.