Hi Markus,
On 16.08.2012 17:07, Markus Hubig wrote:
Dear Andreas,
On Wed, Aug 15, 2012 at 12:55 PM, Andreas Bießmann wrote:
On 14.08.2012 17:11, Markus Hubig wrote:
On Tue, Aug 14, 2012 at 02:03:55PM +0200, Andreas Bießmann wrote:
On 14.08.2012 11:08, Markus Hubig wrote:
On Tue, Aug 14, 2012 at 08:22:11AM +0200, Andreas Bießmann wrote:
On 27.07.12 11:16, Markus Hubig wrote:
<snip>
| int board_early_init_f(void) | { | struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC; | | /* Enable clocks for all PIOs */ | writel((1 << ATMEL_ID_PIOA) | (1 << ATMEL_ID_PIOB) | | (1 << ATMEL_ID_PIOC), &pmc->pcer); | | /* Enable the serial interface */ | at91_set_gpio_output(AT91_PIN_PC9, 1); | mdelay(1000); | at91_seriald_hw_init(); | | return 0; | }
Can you just test the delay in board_init()? I think it should remove the wired characters.
Yes, the strange chars are gone with a small delay after enabling PC9!
| --- a/board/taskit/stamp9g20/stamp9g20.c | +++ b/board/taskit/stamp9g20/stamp9g20.c | @@ -166,6 +166,7 @@ int board_init(void) | | /* Enable the serial interface */ | at91_set_gpio_output(AT91_PIN_PC9, 1); | + mdelay(1); | at91_seriald_hw_init(); | | stamp9G20_nand_hw_init();
And now the output correctly shows "NAND: ..." as the first message course stamp9G20_nand_hw_init() is the first funktion that writes something to the serial line after it is enabled.
great!
Did you investigate the PCB? Which device is directly behind the DB9 connector? Can you find a datasheet for that device and check if it has some power saving features? Can you check if these power saving features switched with the PC9? Did taskit respond to your request for detailed information?
Problem is, I don't have the circuit diagrams and taskit didn't respond yet ...
OK now I got an responce from taskit. PC9 enables the level converter of the RS232 interface. The level converter is a TI MAX3243I. And PC9 is connected to ~FORCEOFF. So in order to get the serial line working PC9 has to be high.
Ok, as I thought ...
Another possible reason can be the fact that you enable the output pins after serial port is enabled (serial_init runs way before board_init).
This is what I think too! But board_early_init_f() is called befor serial_init() so this would be the place to put this, but I don't unterstand why the
| at91_set_gpio_output(AT91_PIN_PC9, 1);
command is not working in board_early_init_f() ...
This works for me: ---8<--- --- a/board/atmel/at91sam9263ek/at91sam9263ek.c +++ b/board/atmel/at91sam9263ek/at91sam9263ek.c @@ -254,6 +254,14 @@ int board_early_init_f(void) (1 << ATMEL_ID_PIOCDE), &pmc->pcer);
at91_set_gpio_output(AT91_PIN_PB28, 0);mdelay(10);at91_set_gpio_output(AT91_PIN_PB28, 1);mdelay(10);at91_set_gpio_output(AT91_PIN_PB28, 0);mdelay(10);at91_set_gpio_output(AT91_PIN_PB28, 1);at91_seriald_hw_init(); return 0;} --->8---
I can see pin toggling, unfortunately not the correct timing (~38 us instead of 10 ms; have to have a look for that). However the PB28 stays high after leaving board_early_init_f().
But it definitly dosn't work here. I checked with an oscilator, if I toggle the pin in board_init() I can nicely see it going high and low but if I toggle it in board_early_init_f() *nothing* happens!
Well as mentioned in my mail the mdelay() can not work in board_eraly_init_f() cause the timers are not setup at this stage. You need to provide some nop-loop based delay here to have proper delay! As mentioned before my at91sam9263 (running at about 200 MHz produce 38 us out of a mdelay(10); I dunno what your g20 variant with about 400 MHz produces here). A simple test could be to move the timer init in a/a/lib/board.c before board_early_init_f in the init_sequence. Then the mdelay() will work as expected!
This seems to be the real problem ... for some reason a can *not* toggle gpio pins in board_early_init_f()! I also double checked this with a LED pin. I bet there is something I need to enable earlier to get the at91_set_gpio_output() command working in board_early_init_f() ...
Have you tried pulling the pin low in board_early_init_f and pull it high later on in e.g. board_init?
Another possibility: Your switching of PC9 in board_early_init_f works correctly but needs some settling. Due to the defective mdelay() in board_early_init_f() you will just see nothing cause it was toggled out after your level shifter was ready. Have you tried pressing <Return> after boot in your terminal when you tested the at91_seriald_hw_init() in board_early_init_f()?
Yes but this dosn't work either ...
damn ...
I even put this into serial_init() but again with no luck ...
Therefore your output is put into the TX register but I don't know what happens then. Eventually the output is delayed until the output pins are enabled in conjunction with the 'SYS' clock. Maybe the TX logic is happily shifting the bits into nirvana until you switch on the output pins. In conjunction with the PC9 thing this could be your problem.
I'll have a look how stuff is done in board_early_init_f() in other boards, maybe I find a hint what to do to enable the use ob PIO pins there ...
BTW: have you seen this patch http://patchwork.ozlabs.org/patch/71772/ before?
Not exactly this one, when I first started to work on the patch I got an old (~2 years) one from taskit ... Damn! Here the PC5 and PC9 pins are nicly named ;(
send a patch (including working serial console output ;)
Best regards
Andreas Bießmann