Disabling board controller for custom board

Go To Last Post
4 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In a previous post, I mentioned that I had made a custom board which was based on the NGW100:

https://www.avrfreaks.net/index.p...

I also found it a challenge to bring up the I2C bus because I found that the SCL line went low when the processor booted, and remained low even when the Busybox prompt was reached.

I suspect that this might have something to do with the fact that my board does not have the board controller chip mentioned here:

https://www.avrfreaks.net/wiki/in...

Is there a way to disable probing for the board controller in the Linux code?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Actually the board controller is completely unused on the NGW, despite documentation to the contrary ;). It's useful for testing TWI functionality on the NGW but the kernel doesn't care about it.

I donno why your SCK is staying low. I've got a copy of the latest kernel here on my compy and if you're using the gpio i2c then the pins are explicitly set _high_ at startup (but with the multidrv flag set so it isn't /pulled/ high, just hanging there). I'd try commenting out the call to platform_device_register(&i2c_gpio_device) and confirm that the pin goes high. If not I'd assume it'd be a hardware problem.

Just a thought, do you have sufficiently strong pullups on your sda/scl lines?

If it does go high and you do have good pullups then I'd try using the hardware twi (which finally seems to be working alright). If the problem _still_ persists well then I'm all outta ideas :)

-S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks once again for your replies, Squidgit.

I tried commenting out the platform_device_register(&i2c_gpio_device) function, but the TWI SCL line is still going low. It appears that SCL is being configured as an input, since when I touch the probes of a multimeter on the SCL pin, my power supply shows that there is a small change in the current consumed by my custom board.

My pullups on the TWI bus are 1.5k to 3.3V.

The two lines on my board pass through only one or two vias, and are mostly on the top layer of my board. I don't think that it is a signal integrity problem.

Perhaps my problem lies in the setup of the usarts in the board.c code. Or perhaps there is a problem with the hardware registers, since I am using the AP7001 chip instead of the AP7000 chip. It should work in a similar fashion to the AP7000 (I hope).

I know that a number of other people on this forum have found it to be a challenging task to enable the usarts.

USART0 is my debug port; the other ports (USART1, USART2, USART3) are used to communicate with system peripherals.

I have been setting up the ports as follows:

void __init setup_board(void)
{
	at32_map_usart(0, 0);	/* USART 0*/
	at32_setup_serial_console(0);

	//Map the other USARTS
	at32_map_usart(1, 1);
	at32_map_usart(2, 2);
	at32_map_usart(3, 3);

        //Alternate setting
        //Does not work since I can see nothing on USART0
        //This setting borrowed from another forum post

	//at32_map_usart(1, 0);   /* USART 1: /dev/ttyS0 */
   	//at32_map_usart(2, 1);   /* USART 2: /dev/ttyS1 */
   	//at32_map_usart(3, 2);   /* USART 3: /dev/ttyS2 */
   	//at32_map_usart(0, 3);   /* USART 0: /dev/ttyS3 */

   	//at32_setup_serial_console(3);	
}

and in the function:


static int __init atngw100_init(void)
{
	//unsigned	i;

	/*
	 * ATNGW100 uses 16-bit SDRAM interface, so we don't need to
	 * reserve any pins for it.
	 */

	at32_add_system_devices();

	//Add the USART devices
	at32_add_device_usart(0);
	at32_add_device_usart(1);
	at32_add_device_usart(2);
	at32_add_device_usart(3);

	//set_hw_addr(at32_add_device_eth(0, ð_data[0]));
	//set_hw_addr(at32_add_device_eth(1, ð_data[1]));

	at32_add_device_spi(0, spi0_board_info, ARRAY_SIZE(spi0_board_info));
	at32_add_device_mci(0, &mci0_data);
	at32_add_device_usba(0, NULL);
/*
	for (i = 0; i < ARRAY_SIZE(ngw_leds); i++) {
		at32_select_gpio(ngw_leds[i].gpio,
				AT32_GPIOF_OUTPUT | AT32_GPIOF_HIGH);
	}
	platform_device_register(&ngw_gpio_leds);
*/



#ifdef CONFIG_BOARD_ATNGW100_I2C_GPIO
	at32_select_gpio(i2c_gpio_data.sda_pin,
		AT32_GPIOF_MULTIDRV | AT32_GPIOF_OUTPUT | AT32_GPIOF_HIGH);
	at32_select_gpio(i2c_gpio_data.scl_pin,
		AT32_GPIOF_MULTIDRV | AT32_GPIOF_OUTPUT | AT32_GPIOF_HIGH);
	platform_device_register(&i2c_gpio_device);
#else
	at32_add_device_twi(0);
#endif


	//Add the image sensor interface
	at32_add_device_isi(0);

	//There is no need to add a master clock for the camera
	//because there is already such a clock on camera board

	return 0;
}

This is a real mystery for me, but it probably has a very simple solution.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Squidgit,

Thank you once again for pointing me in the right direction.

You never run out of ideas. :D I have also learned that the board controller doesn't matter, so this also helped me arrive at my solution.

Quote:

Just a thought, do you have sufficiently strong pullups on your sda/scl lines?

Not really--at least when one resistor has a 'cold' solder joint

:wink:

So both lines are now high after replacing the resistor! I will now try to probe the device to check and see what will happen.

So another million smilies for you as well! :D :D :D