disabling printf via DBG/TXT?

[lpcware]

Content originally posted in LPCWare by fierz on Mon Jun 11 02:52:10 MST 2012
Aloha!

RDB1768cmsis_efsl_lib in a project and have the following problem: when debugging with the Red Probe, everything works fine. When run standalone, the firmware crashes. The problem seems to be the printf function that is called by efsl_lib with calls like so:

DBG((TXT("some text")));

my project uses semihosting, so the printfs show up in the console; I already noticed that my own printfs make the firmware crash if the red probe isn't connected.

How can I fix this? I've tried compiling efsl_lib in release mode to no avail - I can still see the printf output in the console, and the firmware still crashes. But surely there is some way to make these statements mute? I don't feel like searching for all of them and commenting them out, that seems very stupid :-)

[lpcware]

Content originally posted in LPCWare by Kahlveen on Thu Jul 05 08:46:43 MST 2012
Problem solved! It was the mismatch of voltages between what is coming out of the LPC and the what is expected on the PC.

Thank you very much Zero and Serge!

[lpcware]

Content originally posted in LPCWare by serge on Wed Jul 04 00:12:57 MST 2012
My two cents: Your serial to usb converter is expecting RS232 voltage levels (official +12V and -12V) :D. Your board is not providing those (UART levels: 0V and 3.3V). By soldering just a connector to the board without a MAX232 for example your serial to usb converter wont work. So connect an FT230X (UART to USB converter from ftdichip http://www.ftdichip.com) directly to the board.:rolleyes: Or just use a cheap digitus Serial to USB converter and remove the RS232 part like ZERO suggested.

[lpcware]

Content originally posted in LPCWare by Kahlveen on Mon Jul 02 09:35:23 MST 2012
my main purpose with the LPC is to send data serially to a wireless device. I am setting up the serial connection between the LPC and the PC simply to check that

1) I have initialise and open the UART TX/RX pins correctly,

2) To double check that I am sending out the correct data serially,

before I plug the LPC to the wireless device.

Thank you for your advice to connect the UART to USB directly, but the connection between the LPC and the wireless device requires a serial one, which explains the connection made by the previous person working on this, and the ridiculous connectors required(or think i require), as shown in the pictures of my previous updated post.

Thank you very much for your help. I will troubleshoot the issues and will update this thread if i manage to identify the problem. :)

[lpcware]

Content originally posted in LPCWare by Ex-Zero on Mon Jul 02 09:21:14 MST 2012
FTDI:

Future Technology Devices International Limited
Unit 1, 2 Seaward Place
Centurion Business Park
Glasgow
G41 1HH
United Kingdom
Tel: +44 (0) 141 429 2777
Fax: +44 (0) 141 429 2758

See: www.ftdichip.com

As Prolific (http://www.prolific.com.tw/US/index.aspx) they are manufacturing converter. So you can use them both :)

As described in:

#15 of http://knowledgebase.nxp.com/showthread.php?t=1931

it's useful to use an UART-USB converter, instead to convert to RS232 :rolleyes:

Cheap Digitus USB-Serial converter include FTDI chips and are very useful after removing RS232 part :D

See: http://flic.kr/p/bCdFve

---

Quote: Kahlveen
If not, then it should be a problem with the connection(soldering/wiring) am I right? Are there any other areas that I should look at to isolate the problem?

---

I don't know what's your hardware is doing, but now you know that UART3 is working and the next step should be to check your RS232 (with a real RS232 connection) to see if your problem is your RS232-USB converter ;)

[lpcware]

Content originally posted in LPCWare by Kahlveen on Mon Jul 02 08:56:16 MST 2012
oh dear, that's strange. Could it be the connector then? Sorry for the silly question but is FTDI a brand of USB-to-serial converter or a type? I checked under Control panel->devices and I think my connector is a prolific USB-to-serial. Should it make a difference?

1) If not, then it should be a problem with the connection(soldering/wiring) am I right?

2) Could it also be the connection that I used to connect the LPC to the PC? I have uploaded a picture of the connection. The orange is the null female-to-male connector, the yellow is the gender-changer. May I know how you have setup the connection please?

3)  Could you also please suggest possible areas of problems that I should look into?

Thank you very much for your help!

[lpcware]

Content originally posted in LPCWare by Ex-Zero on Mon Jul 02 08:45:25 MST 2012
Good news for me, bad news for you :rolleyes:

It's working :)

Printing with 9600bps from UART3 via FTDI to USB without problems :o

[lpcware]

Content originally posted in LPCWare by Kahlveen on Mon Jul 02 08:20:07 MST 2012
haha, all i have is the board and the soldered connector. I have uploaded the project, it is just a simple test one.

I do not have access to a oscilloscope at the moment, unfortunately. Is there another way to check?

Please let me know if there's any other details that I am not mentioning in my posts.

Thank you!

[lpcware]

Content originally posted in LPCWare by Ex-Zero on Mon Jul 02 07:58:41 MST 2012

---

Quote: Kahlveen
...I am taking over the board from a previous person, and he has soldered the serial connector to the UART3 pins on P0_0 and P0_1

---

No UART0 - ISP connection :eek:

I hope someone gave him a kick in the... :mad:

#1 Did you scope TxD to see a signal / speed ?

#2 If you export and post a complete project, it's easier to test :rolleyes:

[lpcware]

Content originally posted in LPCWare by Kahlveen on Mon Jul 02 07:50:56 MST 2012
Sorry, perhaps I should be clearer about my setup.

The board i am working with has a serial connector(male) soldered onto several pins, including the UART3(P0_0 and P0_1). To connect this to the PC, I attach a null female-to-male connector to it, before plugging this connector to a serial-to-USB converter to connect to my laptop(which does not have a serial port).

Without the null female-to-male connector, the PuTTY terminal is not getting any input from the LPC at all, so I am assuming this connector is correctly used.

Thank you once again!

[lpcware]

Content originally posted in LPCWare by Kahlveen on Mon Jul 02 07:43:35 MST 2012
Hello Zero,

you are absolutely right. Unfortunately, I am taking over the board from a previous person, and he has soldered the serial connector to the UART3 pins on P0_0 and P0_1, and hence my restriction to use UART3. Where possible, I will like to avoid having to remove the connection and re-solder.

I have used to the same USB to serial cable on another device and the PuTTY terminal was able to communicate with it without any problems.

Could it still be a hardware problem or more likely a firmware one?

Thank you very much!

[lpcware]

Content originally posted in LPCWare by Ex-Zero on Mon Jul 02 07:28:41 MST 2012

---

Quote: Kahlveen
The code below are the changes I made to the code to setup a UART3 instead of a UART0

---

:confused:

I'm missing the line:

"I've tested original UART0 code to ensure that USB converter or PuTTY are not kidding me  :)"

[lpcware]

Content originally posted in LPCWare by Kahlveen on Mon Jul 02 06:32:22 MST 2012
Hello,

I am trying to setup a UART3 serial connection from my LPC1769 to my PC to read/print data to a PuTTY terminal. I have imported and adapted the code from uart printf as suggested by this website

http://support.code-red-tech.com/CodeRedWiki/RDB1768cmsisExampleProjects

When i try to run the code, all I get is gibberish on my PuTTY terminal when I tried to printf. When i do a scanf, the execution just hangs there at that line.

The code below are the changes I made to the code to setup a UART3 instead of a UART0.

uart3.h
// PCUART3
#define PCUART3_POWERON (1 << 25)

#define PCLK_UART3 18
#define PCLK_UART3_MASK (3 << 18)

#define IER_RBR        0x01
#define IER_THRE    0x02
#define IER_RLS        0x04

#define IIR_PEND    0x01
#define IIR_RLS        0x03
#define IIR_RDA        0x02
#define IIR_CTI        0x06
#define IIR_THRE    0x01

#define LSR_RDR        0x01
#define LSR_OE        0x02
#define LSR_PE        0x04
#define LSR_FE        0x08
#define LSR_BI        0x10
#define LSR_THRE    0x20
#define LSR_TEMT    0x40
#define LSR_RXFE    0x80

// ***********************
// Function to set up UART
void UART3_Init(int baudrate)
{
    int pclk;
    unsigned long int Fdiv;

    // PCLK_UART3 is being set to 1/4 of SystemCoreClock
    pclk = SystemCoreClock / 4;

    // Turn on power to UART3
    LPC_SC->PCONP |=  PCUART3_POWERON;

    // Turn on UART3 peripheral clock
    LPC_SC->PCLKSEL1 &= ~(PCLK_UART3_MASK);
    LPC_SC->PCLKSEL1 |=  (0 << PCLK_UART3);        // PCLK_periph = CCLK/4

    // Set PINSEL0 so that P0.0 = TXD3, P0.1 = RXD3
    LPC_PINCON->PINSEL0 &= ~0x0f;
    LPC_PINCON->PINSEL0 |= ((1 << 1) | (1 << 3));

    LPC_UART3->LCR = 0x83;        // 8 bits, no Parity, 1 Stop bit, DLAB=1
    Fdiv = ( pclk / 16 ) / baudrate ;    // Set baud rate
    LPC_UART3->DLM = Fdiv / 256;
    LPC_UART3->DLL = Fdiv % 256;
    LPC_UART3->LCR = 0x03;        // 8 bits, no Parity, 1 Stop bit DLAB = 0
    LPC_UART3->FCR = 0x07;        // Enable and reset TX and RX FIFO
}

// ***********************
// Function to send character over UART
void UART3_Sendchar(char c)
{
    while( (LPC_UART3->LSR & LSR_THRE) == 0 );    // Block until tx empty

    LPC_UART3->THR = c;
}

// ***********************
// Function to get character from UART
char UART3_Getchar()
{
    char c;
    while( (LPC_UART3->LSR & LSR_RDR) == 0 );  // Nothing received so just block
    c = LPC_UART3->RBR; // Read Receiver buffer register
    return c;
}

// ***********************
// Function to prints the string out over the UART
void UART3_PrintString(char *pcString)
{
    int i = 0;
    // loop through until reach string's zero terminator
    while (pcString != 0) {
        UART3_Sendchar(pcString); // print each character
        i++;
    }
}

I have also changed the retarget.c so that the functions are calling UART3 instead. I am using a serial to USB converter to connect my LPC to my PC.

Can someone please advise? Also, are the initialisation for the UART3 correct?

Thank you very much in advance!

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Mon Jun 11 13:45:31 MST 2012
Building with the Nohost library variant may the simplest/quickest workaround here, though as Zero points out changing the debug output settings within the project may be a better solution.

http://support.code-red-tech.com/CodeRedWiki/LibraryVariants
http://support.code-red-tech.com/CodeRedWiki/SwitchingCLibrary

The following thread may also provide you with some interesting background information....

http://knowledgebase.nxp.com/showthread.php?t=1921

Regards,
CodeRedSupport

[lpcware]

Content originally posted in LPCWare by Ex-Zero on Mon Jun 11 11:35:05 MST 2012
Your debug.h defines debug behaviour:

    #include <stdio.h>
    #define TXT(x) x
    #define DBG(x) debug x
    #define FUNC_IN(x) ;
    #define FUNC_OUT(x) ;
    #define debug printf

If you don't want to use printf at all, change your defines here:

#define DBG(x) //(x)

[lpcware]

Content originally posted in LPCWare by Rob65 on Mon Jun 11 10:50:53 MST 2012

---

Quote: fierz

my project uses semihosting, so the printfs show up in the console; I already noticed that my own printfs make the firmware crash if the red probe isn't connected.

How can I fix this? I've tried compiling efsl_lib in release mode to no avail - I can still see the printf output in the console,

---

Semihosting sends the printf output over the LPC-Link module to the debugger.
Semihosting is part of the library, in your project properties you'll find a reference to "Redlib (semihost)" or "Newlib (semihost)" and this determines that all printf goes to your debugger console.You should never use the semihosting versions of the library when your target is not connected to the debugger. A you discovered, this will hang your application.
When not connected to the debugger, use any of the "(nohost)" libraries instead. You will have to provide your own functions to write a character to the console (e.g. serial port).

If you want to 'fix' the fact that your application hangs, use a library that does not support semi hosting. I think that efsl is not using any printf(or related) statements in the library so this should do the trick.

To 'fix' printf you'll now need to create some output channel that is used as your console (e.g. a serial port). There is a library (small_printf) somewhere on the NXP website that contains a restricted version of printf. It uses less memory than the complete printf from the standard library yet is still powerful enough to be used in most embedded applications.

Rob

[lpcware]

Content originally posted in LPCWare by researchinnovation on Mon Jun 11 03:30:16 MST 2012

---

Quote: fierz
Aloha!

RDB1768cmsis_efsl_lib in a project and have the following problem: when debugging with the Red Probe, everything works fine. When run standalone, the firmware crashes. The problem seems to be the printf function that is called by efsl_lib with calls like so:

DBG((TXT("some text")));

my project uses semihosting, so the printfs show up in the console; I already noticed that my own printfs make the firmware crash if the red probe isn't connected.

How can I fix this? I've tried compiling efsl_lib in release mode to no avail - I can still see the printf output in the console, and the firmware still crashes. But surely there is some way to make these statements mute? I don't feel like searching for all of them and commenting them out, that seems very stupid :-)

---

Hi....
Try this....
http://www.cplusplus.com/reference/clibrary/cstdio/fprintf/
http://support.code-red-tech.com/CodeRedWiki/UsingPrintf?highlight=%28printf%29


Thanks & Regards.......:)