SAM7-P256 USART demo - can't get it to work right

I have a SAM7-P256 from Olimex and followed the Jim Lynch/Eclipse tutorial and got the blinky working just fine. I’m using the Olimex ARM-USB-OCD and can step the code. BTW - thanks Jim - that was a tremendously good tutorial. In less than an hour I went from 0 to JTAG debugging.

My question relates to the USART routines offered on the Olimex site. I cloned the blinky demo so I could get the scaffolidng from blink that worked, modified the makefile, removed all the extraneous .c files, added USART code (main.c, usart.c, etc), renamed the project, gdb build target name, etc. to line it up with my usart project. I have a good build and can step into the USART code. However, when I connect my terminal software, I’m getting garbage when I let it run, but get back actual characters I type when I single step it

I checked out the USART Mode register and derived that it was setting the USART mode to normal, selected clock of MCK, 8 bits, even parity, and 2 stop bits.

 u_pUSART0->US_MR = 0x08c0;

On the baud rate side, the code set it to 9600 according to the comments:

u_pUSART0->US_BRGR = 313; //((48000000)/9600x16)

So, I set my terminal software to 9600/8/E/2 and I just get garbage.

I redid the calculation for 4800 baud, rebuilt the code, reset my terminal to 4800 baud 8/E/2 and if I type an ‘f’ it echos an ‘F’ plus a ‘~}’.

I noticed that the USART demo code was always masking with an & 0x1ff any character read or written. When I changed that to 0xff and stepped the code, it would echo a lower case ‘f’ to my terminal if I typed an ‘f’. But, if I wasn’t single stepping - just let it run - then typed an ‘f’, I would get garbage back on my terminal.

Another thing I saw from single stepping was after I typed an ‘f’, got back an ‘f’ on my terminal, and kept stepping, it would go back through the read loop and read a 254 value…it was going through twice for each character I typed.

I don’t know if any SAM7-P256 user out there has successfully built and run the USART code from the Olimex web site under Eclipse/Yagarto, but if you have, I’d appreciate getting a copy of it.

Alternatively, if someone could point me to working USART code for the Olimex SAM7-P256, whether from Olimex or not, I would appreciate it.

It seems close, but yet seems very far away from working as it came from Olimex.

Thanks,

Landon

Still working on this but after reviewing the value of the usart mode register, it is 8b, no parity, one stop bit. I was off on the previous look.

I also jumpered the PA5 and PA6 pins on the dev/board breakout together which map to the RX0/TX0 so I could test a loop-back. That worked fine. My terminal was connected by RS-232/0 and I could type through it, so electrically I’m getting signal through to those pins.

Wanted to mention that I finally got this to work. There was an error in the Olimex code in how the clock is setup.

The correct code found in system.c is this:

 //Setting PLL and divider:
  //- div by 5 Fin = 3,6864 =(18,432 / 5)
  //- Mul 25+1: Fout =	95,8464 =(3,6864 *26)
  //for 96 MHz the erroe is 0.16%
  //Field out NOT USED = 0
  //PLLCOUNT pll startup time estimate at : 0.844 ms
  //PLLCOUNT 28 = 0.000844 /(1/32768)
  pPMC->PMC_PLLR = ((AT91C_CKGR_DIV & 0x05) | (AT91C_CKGR_PLLCOUNT & (28<<8)) | (AT91C_CKGR_MUL & (24<<16)));

The one thing that changed was the divisor. The Olimex code had AT91C_CKGR_DIV & 3 instead of 5. Once I fixed that, it worked fine. The comment had it right the code didn’t.

So, anyway, I got a Yagarto version of the RS232 demo running on the SAM7-256 :smiley: