Topic: Pin Mux

I created an add on board for the beta version board with connectors for the 2mm 44-pin LCD connector, the 0.100" 18-pin expansion header and the 4-pin serial comm header.  I connected my I2C devices to the LCD_ENABLE (BANK1_PIN23) and LCD_HSYNC (BANK1_PIN24) pins on the 44-pin LCD connector instead of the 18-pin header in case I wanted to drop the 18-pin connection on a later revision of the board.  I am able to use the regutil application to change the function of pins by setting the bits in the HW_PINCTRL_MUXSEL3 register.  This appears to correctly change the function to I2C but the logic level is always low.  When I connect an external pull-up resistor to the pin the logic level changes to high but the I2C signal on the 18-pin connector stops "toggling" and the serial console outputs messages about not being able to communicate with the accelerometer.

Has anyone been able to work with the pin mux function of the iMX233 (specifically the I2C function) and is there some other register settings I should change?  The manual for the iMX233 is not very clear on how the internal connection is made when using the pin mux functions.  I am not sure if it is even okay to configure I2C function on both sets of pins.

Thanks,
Chris P

Re: Pin Mux

Did you get things working?  It's been a while, but you might want to configure bank 0, pins 30 and 31 as GPIOs, and also kill acceld.  As far as I know, assigning the same function to two pins results in undefined behavior.

Re: Pin Mux

I have not been able to get it work but I found some additional information in the IMX23RM manual.  Do you know the location in the i.MX233 documentation that states the connecting a block (like I2C) to multiple pins is undefined?  I did not see any description of the pin multiplexing circuitry and what happens when blocks are connected.  Some pins have pull-ups and some don't and some pins have a pad/gate keeper and others don't, but it is not clear in the manual.

For proper I2C operation, the appropriate pinmux(s) must be selected before taking the block out of reset.  Failure to select the I2C pinmux selections before taking the block out of reset will cause the I2C clock to operate incorrectly and will require another I2C hardware reset.

If I follow the reset procedure in Section 39.3.10 "Correct Way to Soft Reset a Block" I can stop the I2C block but I can not seem to get it started again.  Right now I am looking at the bootstream source code to determine if I can change the configuration of the LCD header during boot.  I have gotten as far as building my own version of the bootloader (with a longer DEFAULT_WAIT_TIME) and replace chumby_boot.rom image on my SD card.  I am still trying to track down exactly where I need to make changes to the registers to configure the I2C on boot.  I wish I would have tested this before I did a turn on my prototype boards smile

Thanks,
Chris P

Re: Pin Mux

Is I2C code included in the released-bootloader?  It wasn't in the original chumby One release, but it's since been added.  If not, I've got a file here that does I2C.  It's kind of weird, because you need to do DMA -- there's no PIO for reading from I2C.  I can post that if you'd like.

Re: Pin Mux

I don't think there is I2C code in the chumby-boot but I am not trying to control the I2C from the bootloader I want to change the way the way the pin mux is configured for the 44-pin LCD header before the I2C block is brought out of the initial reset.  If I could figure out how to do a "soft" reset of the I2C block (and get it running again) after the board is already booted to linux then I would not have to modify the bootloader.  I would probably create a custom bootloader in the future since I have used some alternate functions for the LCD interface pins and would want to configure the pin mux before booting the kernel in the future.  I have tow paths that I am working on (1) is to configure the pin mux in the bootloader before the block is reset release (2) fingure out how to stop the I2C block, reconfigure the pin mux and then restart using the alternate pins.  Both of these paths should work I just don't have a lot of time to troubleshoot right now.