UART example provides giiberish on 115K2

[lpcware]

Content originally posted in LPCWare by Wenzu on Sat Mar 12 16:20:11 MST 2011
Hi,

I have a problem when I try to run the UART0 at 115K2 baud on a stock LPCXpresso 1769.

Trying the DMA example fresh from the code example provides trash data on the UART output.
",Æ•óâ™0È‘¥ô" which in hex is "90 2C C6 C2 95 F3 E2 99 30 C8 91 A5 F4"

However, when I INIT() the UART at 57600 data is correct. "0123456789ABCDEF"

What I first notice is that there are 13 bytes in the 115K in difference to the 16 bytes correct data.


Trying the non DMA example, loopback works fine at the 57600 baud as is given in the example. However if I try to bump that up to 1152K, exactly the same gibberish appears.

So I started doubting my FTDI, but, connected to other sources at 115K2 confirmed it to operate as expected.

What could be wrong ?? The code is exactly as provided in the "mcb1700.code.bundle.lpc1769.lpcxpresso.zip"

!!Baffled!!

[lpcware]

Content originally posted in LPCWare by larryvc on Thu Mar 17 13:39:34 MST 2011
I am also happy to report that all baudrates work, in loopback, even 921600.:)

They also worked by looping through 2 com ports on the PC, at least the baudrates that are supported by the FTDI USB adapters.

[lpcware]

Content originally posted in LPCWare by larryvc on Thu Mar 17 12:08:47 MST 2011
The code works.:)

The debugger was stopping at the loop and not at the last while(1); in the program.:confused: Probably nothing for the debugger to stop at in the empty while(1); ?

Added a printf("Finished!"); before the while(1); to isolate problem.

The comment is still wrong.

[lpcware]

Content originally posted in LPCWare by larryvc on Thu Mar 17 11:51:37 MST 2011
Previously I was also only looking at the data with Teraterm to isolate baud issues.

Yes. I have it wired as a loopback and passes all the code before this loop.

The data after the DMA transfer is not matching.

The comment is wrong s/b UART1 TX , so probably the code is also.

I'm not fully up to speed with DMA on these chips so maybe someone with more knowledge of DMA on LPCs could try this.

[lpcware]

Content originally posted in LPCWare by Wenzu on Thu Mar 17 11:32:04 MST 2011
Hi Larryvc,

I did not go that far, ie.. till the last comparison check where its getting stuck for you.

Isn't the connection supposed to be a physical loopback ??

[lpcware]

Content originally posted in LPCWare by larryvc on Thu Mar 17 11:10:31 MST 2011
Wenzu I am getting stuck at the last loop in udmatest.c

 
/* The data is transferred from M2U0TX-U1RX-, M2U1TX-U0RX. */
/* Between UART0 TX and UART0 RX, the data should match, or fatal DMA error. */
u1_src=(uint8_t *)UART1_DMA_TX_SRC;
u1_dst = (uint8_t *)UART0_DMA_RX_DST;
for ( i = 0; i < UART_DMA_SIZE; i++ )
{
if ( *u1_src++ != *u1_dst++ )
{
while ( 1 );
}
}
 

How is you hardware setup?

[lpcware]

Content originally posted in LPCWare by Wenzu on Tue Mar 15 18:31:33 MST 2011
Thanks Larryvc. Greatly appreceated !!
Your answers have been very helpful.

Hope this thread will help other n000bs when faced with the same issue.
:)

[lpcware]

Content originally posted in LPCWare by larryvc on Tue Mar 15 18:17:03 MST 2011
Wenzu,

#define PLL0CFG_Val 0x0040063   Change the PLL0 Pre-divider to 4 gives 120MHZ

[lpcware]

Content originally posted in LPCWare by Wenzu on Tue Mar 15 15:31:11 MST 2011
Hi, Just changing  [COLOR=black]#define PLL0CFG_Val 0x0050063 //0x0000000B got the 115k2 to work ok. same with 57k6.
did not try other values..perhaps later.

As for my previous comment, of course, peripherals using the clock as their reference need to be fixed.
This wasn't an issue at all, simply by clocking a desired output, and fixing the registers to give me the appropriate signal seen on a DSO. The one I spent most time to get was the SSP, where both the LPC_SSP0->CPSR prescaler and the LPC_SSP0->CR0 needed to be fixed.
Also, timer, pwm etc are nicer and rounder to work out since the clock is now at 100MHz.
Next is a test at 120Mhz.

[/COLOR]

[lpcware]

Content originally posted in LPCWare by tkopriva on Tue Mar 15 15:04:08 MST 2011
Hi,

The sample code bundle doesn't configure the UART fractional divider that would be needed to get the proper baudrate for 115.2 Kbps (CPU Core @ 72Mhz where the UART clock divider is set to 4).

There are a few options here:

[LIST]
[*]Manually determine the fractional divider. (Geared specifically towards 115.2Kbps)
[*]Configure the UART clock divider to divide by 1 (Increases current consumption)
[*]Increase the CPU clock to 100MHz may also work...not sure though.
[/LIST]
The quickest fix is to the change the UART clock divider to 1 if you are running the CPU @ 72MHz. (Check the PCLKSEL register)

Did this help/work?

---

Quote: Wenzu
Hi,

I have a problem when I try to run the UART0 at 115K2 baud on a stock LPCXpresso 1769.

Trying the DMA example fresh from the code example provides trash data on the UART output.
",Æ•óâ™0È‘¥ô" which in hex is "90 2C C6 C2 95 F3 E2 99 30 C8 91 A5 F4"

However, when I INIT() the UART at 57600 data is correct. "0123456789ABCDEF"

What I first notice is that there are 13 bytes in the 115K in difference to the 16 bytes correct data.


Trying the non DMA example, loopback works fine at the 57600 baud as is given in the example. However if I try to bump that up to 1152K, exactly the same gibberish appears.

So I started doubting my FTDI, but, connected to other sources at 115K2 confirmed it to operate as expected.

What could be wrong ?? The code is exactly as provided in the "mcb1700.code.bundle.lpc1769.lpcxpresso.zip"

!!Baffled!!

---

[lpcware]

Content originally posted in LPCWare by Wenzu on Tue Mar 15 09:13:04 MST 2011
hi Larryvc, Thanks for your reply.
I will look into these very soon. I really want to know what effect it does to my other peripherals running at the moment.. I2C, SSPDMA, Timers..

[lpcware]

Content originally posted in LPCWare by larryvc on Tue Mar 15 08:55:11 MST 2011
I should have said that I had to revert to the original longer definitions to get it working with CMSISv1p30.

Yes it works with CMSISv2 when you change the value of PLL0CFG_Val but SystemInit and SystemClockUpdate in CMSISv2 are not quite right yet in setting up the clocks.

[lpcware]

Content originally posted in LPCWare by Wenzu on Tue Mar 15 01:23:45 MST 2011
hi larryvc, thanks for pursuing the subject ;)

two points:

[LIST]
[*]as soon as I changed to [COLOR=black]#define PLL0CFG_Val 0x0050063 //0x0000000B,  115k2 was spitting out well, as well as other bauds !![/COLOR]
[*][COLOR=black]when I opened up lpc17xx.h, I already found my struct to be as in your second code clip.. ie shortened.[/COLOR]
[/LIST]
Now, on to re-tune some registers for peripherals.
Thanks !!!

[lpcware]

Content originally posted in LPCWare by larryvc on Mon Mar 14 20:09:13 MST 2011
I modified the UARTDMA example to use CMSISv1p30_LPC17xx and it correctly sets the SystemCoreClock to 100MHZ and 115200 baud is working.:)

So there is work to be done on CMSISv2_LPC17xx system init and core clock routines.

One thing that may impact migration of existing code to CMSISv2_LPC17xx is the shortened TypeDef variable names ie.

typedef struct                          /* Channel Registers                  */
{
  __IO uint32_t DMACCSrcAddr;
  __IO uint32_t DMACCDestAddr;
  __IO uint32_t DMACCLLI;
  __IO uint32_t DMACCControl;
  __IO uint32_t DMACCConfig;
} LPC_GPDMACH_TypeDef;

typedef struct                              /* Channel Registers                  */
{
  __IO uint32_t CSrcAddr;                   /*!< Offset: 0x000 (R/W)  DMA Channel # Source Address Register */
  __IO uint32_t CDestAddr;                  /*!< Offset: 0x004 (R/W)  DMA Channel # Destination Address Register */
  __IO uint32_t CLLI;                       /*!< Offset: 0x008 (R/W)  DMA Channel # Linked List Item Register */
  __IO uint32_t CControl;                   /*!< Offset: 0x00C (R/W)  DMA Channel # Control Register */
  __IO uint32_t CConfig;                    /*!< Offset: 0x010 (R/W)  DMA Channel # Configuration Register */
} LPC_GPDMACH_TypeDef;

I had to change these to get the code to work.

[lpcware]

Content originally posted in LPCWare by larryvc on Mon Mar 14 12:46:18 MST 2011
[LEFT][COLOR=#7f0055][COLOR=#7f0055][COLOR=black]CMSISv2_LPC17xx has changed the system init and core clock routines.[/COLOR][/COLOR][/COLOR][COLOR=#7f0055][/LEFT]

[LEFT][COLOR=#7f0055][COLOR=black]In the file System_LPC17xx.c I changed the define below and got 99MHZ for SystemFrequency. That's better than the 72MHZ received before. I would like to see 100MHZ at least.[/COLOR][/COLOR][/COLOR][/LEFT]

[LEFT][COLOR=black]#define PLL0CFG_Val 0x0050063 //0x0000000B[/COLOR][/LEFT]

[LEFT][COLOR=black]I don't know if CMSISv2 is supported yet by CodeRed but there may be problems with the way the new code handles these routines.[/COLOR][/LEFT]

[lpcware]

Content originally posted in LPCWare by Wenzu on Sun Mar 13 04:12:22 MST 2011
@KTownsend, Like I said, the RX end on my PC is working fine with an FTDI on Com4, Windows 7. Used various terminal progs too...

Thanks larryvc for confirming my doubts that on higher bauds.
Surely,the clocking isn't correct.

[lpcware]

Content originally posted in LPCWare by larryvc on Sun Mar 13 01:40:10 MST 2011
I am assuming you are talking about the UARTDMA example that uses CMSISv2_LPC17xx.

While debugging on an LPCXpresso1769 I noticed the following:

The call to SystemClockUpdate() in udmatest.c sets SystemFrequency to 72MHZ.

This in itself is a problem as SystemCoreClockUpdate in CMSISv1p30 sets SystemCoreClock to 100MHZ. [SIZE=1][I]Shouldn't this be 120MHZ on a 1769.[/I][/SIZE]

I don't think UARTInit in uart_dma.c is setting the baudrate correctly based on the value SystemFrequency is set to. [SIZE=1][I]Then again I might be wrong.[/I][/SIZE]

Just using TeraTerm, and other terminal programs, to capture what was sent at 57600 and 115200.

57600 good. 115200 BAD. Still investigating.

[lpcware]

Content originally posted in LPCWare by ktownsend on Sat Mar 12 22:51:42 MST 2011
A bit more information would be helpful.  What OS, for example, or what's on the receiving end?  If Windows, have you also set the port to 115K in the Device Manager, for example?