>I think you should try to find out why the baud rate is incorrect. This problem will perpetuate itself when you start dealing with timers.
I have found the problem, it really took me time because I was fooled by the fact that the board needs to be powered down some seconds between each test. I don't have any reset button...

Well, I tried the spreadsheet into the files section and apparently the only one combination I should use is M=2 and P=4 (and not M=2 and P=2), with APBDIV= 1 and it gives me 115200 baud. So far so good (not much testing but...).

>I don't think the answer is no. But, for me, it is a bit of sophistication that I neither need nor want.
Sorry, I was meaning to say it is far from my expertise...I am still reading the doc you referenced

Ok now:

1) Is it possible to use gbd/insight to debug this demo? I am unable to do it, really out of clue here. I got an errors:

C:\temp\FreeRTOS\Demo\ARM7_LPC2106_GCC.test2/LPC2106_flash.gdb:8: Error in sourced command file:
Memory access error while loading section startup.
And then I get lost into integer.c and some isr routine, shouldn't it start with a breakpoint in main.c ? Do I have to disable interrups or what?

This is my gdb file:

target remote localhost:3333
monitor soft_reset_halt
monitor arm7_9 sw_bkpts disable
monitor arm7_9 force_hw_bkpts enable
monitor mww 0xE01FC040 0x0001
monitor mdw 0xE01FC040
break main
load
continue
2) Any clue on how to port it in Eclipse? I will try but I guess is not trivial

TIA,

Giuseppe

On 12/17/2009 3:59 PM, rtstofer wrote:
>
> --- In l..., Giuseppe Marullo wrote:
>
>>
>>> Yes, you can use printf(). But I believe you have to implement various stubs in syscalls to create stdout.
>>>
>> Ouch, short answer is no then....
>>
>> Giuseppe
>>
>>
> I don't think the answer is no. But, for me, it is a bit of sophistication that I neither need nor want.
>
> OTOH, there is an rprintf.c file in the Group's Files folder that implements a subset and doesn't require the heap or syscalls.
>
> You might try to Google for 'ARM7 printf'. The very first response "ARM Projects" apparently shows you just what is needed for stdio printf().
>
> There's an explanation over here: http://openhardware.net/Embedded_ARM/NewLib_Stubs
>
> I think you should try to find out why the baud rate is incorrect. This problem will perpetuate itself when you start dealing with timers.
>
> In fact, try to set up a timer to blink the LED at some frequency and see if it works out properly.
>
> Richard
>

--- In l..., Giuseppe Marullo wrote:
>
> >Yes, you can use printf(). But I believe you have to implement various stubs in syscalls to create stdout.
>
> Ouch, short answer is no then....
>
> Giuseppe
>

I don't think the answer is no. But, for me, it is a bit of sophistication that I neither need nor want.

OTOH, there is an rprintf.c file in the Group's Files folder that implements a subset and doesn't require the heap or syscalls.

You might try to Google for 'ARM7 printf'. The very first response "ARM Projects" apparently shows you just what is needed for stdio printf().

There's an explanation over here: http://openhardware.net/Embedded_ARM/NewLib_Stubs

I think you should try to find out why the baud rate is incorrect. This problem will perpetuate itself when you start dealing with timers.

In fact, try to set up a timer to blink the LED at some frequency and see if it works out properly.

Richard

>Yes, you can use printf(). But I believe you have to implement various stubs in syscalls to create stdout.

Ouch, short answer is no then....

Giuseppe

--- In l..., Giuseppe Marullo wrote:

> I could live with the baud rate for now, I need to know about the printf...is it possible to use with the output on the uart?
> Actually I can't debug either, so printf is the bare minimum.
>
> Giuseppe
>

Yes, you can use printf(). But I believe you have to implement various stubs in syscalls to create stdout.

Look at www.jcwren.com/arm for code that implements EVERYTHING on an LPC2148. This code revolves around FreeRTOS and it's excellent.

HOWEVER, many people don't want to implement syscalls and especially don't want to use stdio (or any part of newlib, for that matter). Both printf and sprintf bring along a lot of code and require a heap and its management.

You can always write things like putc(), puts(), puthexWord(), puthexByte(), putDec(), etc. They are trivial to code, require no heap and are easy to debug. I ALWAYS write these for a new chip right after I get the UART working. I almost never use JTAG so I need them for debugging.

Conversion functions like itoa() come right out of "The C Programming Language" by Kernighan & Ritchie.

Richard

Richard,

>#define configCPU_CLOCK_HZ ( unsigned long ) 58982400 )
>in FreeRTOSConfig.h?
>Did you change configCPU_CLOCK_HZ to match your 48MHz setup?

Yes, I did:
#define configCPU_CLOCK_HZ ( ( unsigned long ) 48000000 )

>Have you looked at how the baudrate is calculated in Serial.c?
I tried to follow the code, nothing special configCPU_CLOCK_HZ is used to get the UART clock (16x).
I don't know much about FreeRTOS but it does seem it is the right way.

I could live with the baud rate for now, I need to know about the printf...is it possible to use with the output on the uart?
Actually I can't debug either, so printf is the bare minimum.

Giuseppe

--- In l..., Giuseppe Marullo wrote:
>
> Hi Daniel and Martin and others,
> thanks for all your help.
>
> I have 24MHz of clock (Fosc), AFAIK the maximum supported by LPC2138 is
> 60MHz. So 48MHz (desired CCLK) should be the maximum frequency, right?
>
> CCLK = M x Fosc or
> CCLK = Fcco / (2 x P)
>
> So M = 2
>
> PO /(CCLKx2)
>
> P can vary between 156e6/(CCLKx2) = 1.625 and 320e6/CCLKx2)= 3.333, so
> the only selectable P must be 2.
>
> Value for PCON [6:5/4:0] >
> [10 0001] = 0x21
>
> APBDIV is set for Same clock, so:
>
> SCB_VPBDIV = mainBUS_CLK_FULL;
>
> Now, the question:
>
> why this:
>
> #define mainCOM_TEST_BAUD_RATE ( ( unsigned long ) 115200 )
>
> Gets me with 230k baud instead of 115k? Surely it is my fault, simply I
> don't understand why.
>

Have you looked at how the baudrate is calculated in Serial.c?

What about the definition:

#define configCPU_CLOCK_HZ ( unsigned long ) 58982400 )

in FreeRTOSConfig.h?

Did you change configCPU_CLOCK_HZ to match your 48MHz setup?

I still don't know how you got twice the baudrate but I do know how you could get a little bit off.

As to getting UART1 to work, that will be trivial once you get the various clocks and dividers working.

Richard

Hi Daniel and Martin and others,
thanks for all your help.

I have 24MHz of clock (Fosc), AFAIK the maximum supported by LPC2138 is
60MHz. So 48MHz (desired CCLK) should be the maximum frequency, right?

CCLK = M x Fosc or
CCLK = Fcco / (2 x P)

So M = 2

PO /(CCLKx2)

P can vary between 156e6/(CCLKx2) = 1.625 and 320e6/CCLKx2)= 3.333, so
the only selectable P must be 2.

Value for PCON [6:5/4:0]
[10 0001] = 0x21

APBDIV is set for Same clock, so:

SCB_VPBDIV = mainBUS_CLK_FULL;

Now, the question:

why this:

#define mainCOM_TEST_BAUD_RATE ( ( unsigned long ) 115200 )

Gets me with 230k baud instead of 115k? Surely it is my fault, simply I
don't understand why.

Other questions:

- I would like to use the UART1, is there a way to compile the demo
and/or tell the console is UART1 instead of UART0? I remember there was
a option in the makefile on the LPC2148 demo CFG_CONSOLE_UART1 but is it
just for it or it is a "feature" of freertos?

- is it possible to use printf instead of sprintf and have its output on
serial? Or, any printf substitute that could output using the printf
formatting ?

- Is it possible to debug using gdb/insight a freertos program? I tried
but probably due to ISR or something it does not start at main,c I
succesfully debug Xylo-LM examples both in ram and flash from Eclipse
and Insight

Thanks,

Giuseppe Marullo
>Since the last eq may not satisfy the minimum UART error rate, you can set the fractional divider. Read the LPC2138 User Manual for the details.
This does not apply here, sorry. Apart for error mine is a LPC2138 that does not have fractional divider (as LPC2138/01), or there is something I don't know.

Daniel Widyanto wrote:
> Hi,
>
> The LPC PLL block is an analog block that needs to be operated at certain frequency to guarantee its frequency stability. For LPC2138, it needs to be in 156Mhz-320Mhz. Otherwise, even though it's running, its frequency may be jittered (shifted up or down during the system operation).
>
> For your case:
> CCLK = your CPU core speed = Fosc x M -> Suggested to put it higher to achieve better performance, or lower to conserve power
> Fcco = the PLL clock freq = CCLK x 2 x P -> Must be in the range of 156Mhz - 320Mhz
> UART clock = PCLK = CCLK / APBDIV -> Read the LPC2138 user manual
>
> UART baudrate = UART clock / (16 x DLAB-in-16-bits-value)
>
> Since the last eq may not satisfy the minimum UART error rate, you can set the fractional divider. Read the LPC2138 User Manual for the details.
>
> Regards,
> -daniel
>
> From: l... [mailto:l...] On Behalf Of Giuseppe Marullo
> Sent: Tuesday, December 15, 2009 9:22 AM
> To: l...
> Subject: Re: [lpc2000] Re: LPC2138 another try on freertos
>
>
> Richard,
> I have tried this one too in the past. Today I was able to compile it
> and got something working. What and why is working is still not clear to
> me..
>
> 1) I am using UART1 now, I changed the way the FPGA connects to the ARM.
> I just have the tx pin for now.
>
> 2) I changed the usual bunch of stuff, and now I have one led flashing
> (0x40000000). The UART0 is spitting a sequence of chars A..X (not Z)
> @115200 probably there is some error in the stack definition or memory
> map...I don't know
>
> The clock is 24MHz, and I set M=2 P=1. I don't know if this is the right
> setting, but it works for 115200. What puzzles me is that Fcco < 156MHz,
> but as long I get 115200 I will solve this later.
>
> In freertos.h I changed
> #define configCPU_CLOCK_HZ ( ( unsigned long ) 48000000 )
> /* $MHz osc (fx2) multiplied by 2 using the PLL. */
>
> In main.c I changed:
>
> SCB_PLLCFG = 0x20; // P=2 [01] and M=1 [00000]
>
> I was expecting to use 0x21 (M=2,P02) , but apparently it goes 230k.
>
> Do you know what I could have set wrong for the serial port having this
> behavior?
>
> Thanks for you time,
>
> Giuseppe Marullo
>
> Serial output:
> ...
> MNOPQRSTUVWXABCDEFGHIJKLMNOPQRSTUVWXABCDEFGHIJKLMNOPQRSTUVWXABCDEFGHIJKLM
> NOPQRSTUVWXABCDEFGHIJKLMNOPQRSTUVWXABCDEFGHIJKLMNOPQRSTUVWXABCDEFGHIJKLMNOPQRSTU
> ...
>

>The only part I can get into right now is the serial output. If you look at comtest.c (in the common folder), you will >see that it only sends A..X
So does the output make sense? Great. I was expecting something more "meaningful".

>I'm not sure which demo you started with. The LPC2106-GCC or the LPC2148-ROWLEY?
This is the LPC2106 GCC demo.

>Remember, you calculate M but you write M-1 to the register.
More on this later, I am in hurry.

Thanks for now,

Giuseppe

To take a 12 MHz crystal up to 60 MHz (full speed) for the 2148:

static void feed(void);

/**********************************************************
Initialize
**********************************************************/

#define PLOCK (1 << 10)

void PLL_init(void) {

// Setting Multiplier and Divider values
PLL0CFG = 0x24; // P=2, M=5
feed();

// Enabling the PLL */
PLL0CON = 0x1;
feed();

// Wait for the PLL to lock to set frequency
while(!(PLL0STAT & PLOCK))
;

// Connect the PLL as the clock source
PLL0CON = 0x3;
feed();

// Enabling MAM and setting number of clocks used for Flash memory
fetch (3 cclks in this case)
MAMTIM = 0x03;
MAMCR = 0x02;
//MEMMAP = 0x01;

// Setting peripheral Clock (pclk) to 1/4 System Clock (cclk)
VPBDIV = 0x00;
}
void feed(void)
{
PLL0FEED=0xAA;
PLL0FEED=0x55;
}
To set the UART0 for 115200,n,8,1:

// we are assuming a PCLK of CCLK (60 MHz) / 4 or 15 MHz

// set UART0 for 115200,n,8,1

void UART0_init(void)
{
PINSEL0 |= 0x05; // enable UART0 pins
U0LCR = 0x83; // 8,n,1 and turn on DLAB
U0DLM = 0x00;
U0DLL = 0x05; // divide PCLK by 5
U0FDR = (8 << 4) + 5; // multiply by 8, divide by 8 + 5
U0LCR &= ~(0x80); // turn off DLAB
U0FCR = 0x07; // reset and enable FIFO, RX Trigger level 0 - 1 char
}

Since the peripheral clock is 15 MHz, you need to see how the tick timer is set up. I don't have the FreeRTOS code on this machine. And I'm not sure whether you started with the 2106 version or the 2148.

Richard

An Engineer's Guide to the LPC2100 Series