printf function on the DEMOQE128 board.

[Bugman2960]

I have a DEMOQE128 board with the 32-bit MCF51QE128 processor and am trying to use the printf function to send data out the serial port.  The code compiles and builds fine, but nothing comes out the serial port when the function is called.  All jumpers are in their proper positions. 

I can send other data using the  AS1_SendChar function however while using the printf function nothing is transmitted.

When I step through the code it appears to be doing the printf function with the data I have in the function, but I never see anything on the serial port.  The transmitter is assigned to PTB1. 

I'm sure this is something very simple I'm overlooking.

Any help is greatly appreciated.

Thank you.

[CrasyCat]

Hello

I assume you are using CodeWarrior for MCU V6.0, you are debugging on a real hardware board and you want to see the output of the printf in the debugger Terminal window.

I also assume you have created your project using the project wizard.

Am I right?

In order to activate console I/O on a MCFQE128 you need to:

  - Edit the file exceptions.c from your project.

  - Change

      #define CONSOLE_IO_SUPPORT  0 
    to

      #define CONSOLE_IO_SUPPORT  1
  - Add the file {Install}\ColdFire_Support\msl\MSL_C\MSL_ColdFire\Src\console_io_cf.c

    to your project

  - Rebuild your project

  - Start the debugger

  - Select "CFMultiLinkCyclonePro" -> "Setup" or "Softec-MCF51" -> "Setup" depending how

     you are connected to the board.

  - Switch to the "Debug Options" tab

  - Check "Enable terminal printf support"

  - Click OK to close the dialog.

You may have to restart the debugger to activate the change.

That should do it.I hope this helps.

CrasyCat

[wdfarmer1]

Crasycat, I have a similar question.  I'm using:

CodeWarrior 10.0 Beta 3

DEMOQE128 board

and am building to the MCF51QE128 internal flash target.  I've written a simple C++ application that sends some output using "cout", e.g.  cout << variable.

First of all, I'd like to be able to to use cout to write to the CW console window, even if there's no DEMOQE128 board connected, but I haven't found yet how to invoke the full chip simulation in the debugger (something that was present in CW 5 and 6).  Do you know if CW 10.0 Beta 3 supports simulation?

Second, I haven't found yet how to get a successful build with "cout" in the source.  I do have -define CONSOLE_IO_SUPPORT=1 in the compile flags.  Here's what goes wrong:

1.  If I use #include <iostream> in my source, I get a failure, with "undefined identifier cout" in the compile.

2.  If I use <iostream.h> instead, I get these 3 symbols undefined in the link:  InitializeUART, ReadUARTN, WriteUARTN

There are 3 files in C:\Program Files\Freescale\CW MCU v10.0\MCU_10.0\ColdFire_Support\ewl\EWL_C\src\coldfire:  console_io_cf.c, sci_console_io_cf.c, and uart_console_io_cf.c, but I don't see how they would help.

Am I missing additional includes in my build?  Additional sources?  Help would be appreciated.  Thanks!

[wdfarmer1]

Follow-up:  If I use #include <iostream> but add the statement  using namespace std; "cout" is recognized by the compiler, but then I get the same 3 symbols undefined in the link:  InitializeUART, ReadUARTN, and WriteUARTN.

Again, my objective is to get "cout" output to the console window in the debugger, not to the actual UART hardware.

[wdfarmer1]

2nd follow-up:  Adding a copy of

C:\Program Files\Freescale\CW MCU v10.0\MCU_10.0\ColdFire_Support\ewl\EWL_C\src\coldfire:  console_io_cf.c

to my build fixed the message about the 3 underined symbols, and got me a good build.  Whether it will succeed in sending "cout" output to the console remains to be seen; I'm working on another unrelated problem now, which I'll post under a different heading elsewhere.

[wdfarmer1]

Ok.  I've got console_io_cf.c included in my build, and it issues a Trap 14 when it wants to perform console output.  However, immediately after it does so, CW 10.0 beta 3 reports that the USB interface reports "Not ready", and the debug session halts.  What do I need to change in Processor Expert and/or the Debug Configuration to handle the Trap 14?

1.  Processor Expert's Trap 14 is currently disabled; if enabled, it would generate an exception vector entry for that trap... but where should that vector point?  Is there an exception handler for Trap 14 that I'm not including in my build?

2.  Debug Environment currently has both "Terminate on Trap 14" and "User Application Handles Trap 14" checked.  Making changes in either of both of those doesn't currently help.

Wayne

[vamfun]

Hi,

I too have the DEMOQE128.  I used your procedure to get printf working but its output is very very slow...  I estimate about 8 char per second to the Terminal screen.  

I am running a modified Accelerometer demo using the SCI inits.   It writes fine to the PEMICRO grapher utility but will not work with the PEMICRO Terminal utility.  I thought this might be faster than the Terminal window in Coldfire Debug.    The PEMICRO terminal window will print out stuff sent with the SendMsg() function but not the printf().  

I tried to increase the baud argument used in the  InitSCI(baud) function.  It did not help.

Also noticed that the printf() inhibits the PEMICRO Grapher while its printing to Terminal Screen.  This probably is normal behavior when two users are requesting SCI interrupt time.

Any thought on how to speed things up?

Thanks

[Bugman2960]

CrasyCat,

Thank you for the information.

You are absolutely correct with all your assumptions.

I made all the changes you suggested and enabled the printf support in the debugger however it still does not send anything out of the serial port.  It compiles fine but gives me 103 warnings about overlap violations. 

Do you have any other suggestions?

See the attached screenshot of the project.

Thank you again.

[CrasyCat]

Hello

OK, then at least one of my assumptions was wrong .

You are not looking to redirect stdout to the Console window, but to the UART.

In that case, you have to use the file

{Install}\ColdFire_Support\msl\MSL_C\MSL_ColdFire\Src\uart_console_io_cf.c instead of

{Install}\ColdFire_Support\msl\MSL_C\MSL_ColdFire\Src\console_io_cf.c in your project.

You then need to provide implementation for the low level functions InitializeUART, ReadUARTN and WriteUARTN.

InitializeUART is used to initialize (configure) the SCI.

ReadUARTN is sued to read n characters from the SCI port.

WriteUARTN is used to send n characters through the SCI.

Prototypes for these functions are available in

    {Install}\ColdFire_Support\msl\MSL_C\MSL_Common_Embedded\Include\uart.h

I did not find a sample implementation for them.

I hope this helps.

CrasyCat

[CrasyCat · Accepted solution]

Hello

I gave this one a further check as well.

Basically to get printf redirected to UART:

   - Make sure CONSOLE_IO_SUPPORT is set to 0 in exceptions.c

   - Add the file {Install}\ColdFire_Support\msl\MSL_C\MSL_ColdFire\Src\uart_console_io_cf.c to

     your project

  - Edit the file uart_console_io_cf.c

  - Remove line 90 from this file:

#pragma overload int __write_console(__file_handle handle, unsigned char * buffer, size_t * count, __std(__ref_con) ref_con);

  - Add an implementation of InitializeUART, ReadUARTN and WriteUARTN. I attached a sample

    implementation that worked on my DEMOQE128 board. You may have to adjust it to your own

    hardware. It is just an example.

  - Make sure "Enable Terminal printf support" is unchecked in the debugger Debug Options.

Attached file defined a baud rate of 19200 for UART. To change Baud Rate modify UART_CONSOLE_BAUD_RATE  in uart_console_config.h

Enjoy

CrasyCat

[Bugman2960]

CrasyCat,

Thank you.

After making your changes it seems to be working fine.

Although the timing is a little off... no big deal.

It's running off the internal oscilator.

I'm going to add the external XTAL to get it on a real baud rate freq. then tweak the regs to get it right on.

Thanks again.

Kevin

[CrasyCat]

Hello

I am glad I could help here.

Keep in mind that the file I have delivered is only a sample implementation. Depending on the hardware you are using you may need to adjust HW configuration.

Looks like you need to adjust clock settings in your case..

CrasyCat