double printf() before main()

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
RiKw_4278376
Level 2
Level 2
5 replies posted 5 questions asked First question asked

I'm building a simple printf() example based on the "Welcome to ModusToolbox" training videos at https://www.cypress.com/products/modustoolbox-software-environment.

I indeed got the "x = ..." counter to print, but to my surprise, it prints twice before entering main() in the debugger..  Here is a snap of the paused session. mt-dev1-main-debug-start.png

The debugger has stopped on line 39 of main.c; that happens to be the open brace '{' after 'int main(void)'.  Already, the printf() statement has executed twice.  If I let it continue, it will print at one-second intervals, starting from "x = 0" as is first expected, until I stop the process.

mt-dev1-main-debug-cont.png

Actually, this is not the first time I've seen this behavior.  I had added some printf() statements in a SMIF example to read the JEDEC ID and print it out.  To my shock, the JEDIC ID code and the printf() were executed twice before reaching main(). I decided that example was possible too complex, and decided to do something much simpler, like this example.

I've done this with ModusToolbox on macOS as well as on Windows 10.  I wonder if I've been systematically overlooking something. I've attached the design.modus file and the three files within the Source directory.

The version of ModusToolbox on macOS is Version: 1.1.0, Build ID: 234.  I don't know the version on Windows 10, but I had installed in sometime in the last 3 months.

0 Likes
1 Solution
MotooTanaka
Level 9
Level 9
Distributor - Marubun (Japan)
First comment on blog Beta tester First comment on KBA

Hi,

I think that I've seen similar symptoms with other IDEs, including PSoC Creator.

This time at first I wondered why two printf()s are generating same result,

as count is being incremented.

Anyway, as I have not used ModusToolBox for a while,

I took advantage of this topic for my rehabilitation of MTW 😉

I used PioneerKitApp from code example.

I modified main.c as follows

===================

#include "cycfg.h"

#include "cycfg_capsense.h"

#include "stdio.h"

int main(void)

{

int count = 0 ;

cy_stc_scb_uart_context_t uart_context ;

    /* Set up the device based on configurator selections */

    init_cycfg_all();

    __enable_irq();

    Cy_SCB_UART_Init( KIT_UART_HW, &KIT_UART_config, &uart_context ) ;

    Cy_SCB_UART_Enable( KIT_UART_HW ) ;

    for(;;)

    {

    Cy_GPIO_Inv( KIT_LED1_PORT, KIT_LED1_PIN ) ;

    printf( "Message #%d\r\n", ++count ) ;

    Cy_SysLib_Delay( 1000) ;

    }

}

===================

The result was just like yours, but as it had "++count" the number was 1.

lab0_teraterm.JPG

Here, as we see the same number again,

I assumed that the program was executed twice

before the debugger finally took control of the MCU.

So to test it, I modified main.c as below.

I added "ModusToolBox Test" message before the loop, so that I could tell

if the loop was executed twice, or whole program was started twice.

==========================

#include "cy_device_headers.h"

#include "cycfg.h"

#include "cycfg_capsense.h"

#include "stdio.h"

int main(void)

{

int count = 0 ;

cy_stc_scb_uart_context_t uart_context ;

    /* Set up the device based on configurator selections */

    init_cycfg_all();

    __enable_irq();

    Cy_SCB_UART_Init( KIT_UART_HW, &KIT_UART_config, &uart_context ) ;

    Cy_SCB_UART_Enable( KIT_UART_HW ) ;

    printf("ModusToolBox Test %s %s\n\r", __DATE__, __TIME__) ;

    for(;;)

    {

        Cy_GPIO_Inv( KIT_LED1_PORT, KIT_LED1_PIN ) ;

        printf( "Message #%d\r\n", ++count ) ;

        Cy_SysLib_Delay( 1000) ;

    }

}

==========================

The result was

lab1_teraterm.JPG

Apparently the initial part and the beginning of the main loop was executed twice.

I think that the time took before the debugger was long enough to allow the MCU free run up to that point,

meantime it was executed twice, I imagine that  "power on" or "write flash complete" and "reset" from the debugger

cause two start ups for the MCU.

So I modified main.c as below.

I added "1 sec" delay before the main loop which contains the "printf()"

========================

#include "cy_device_headers.h"

#include "cycfg.h"

#include "cycfg_capsense.h"

#include "stdio.h"

int main(void)

{

int count = 0 ;

cy_stc_scb_uart_context_t uart_context ;

    /* Set up the device based on configurator selections */

    init_cycfg_all();

    __enable_irq();

    Cy_SCB_UART_Init( KIT_UART_HW, &KIT_UART_config, &uart_context ) ;

    Cy_SCB_UART_Enable( KIT_UART_HW ) ;

    Cy_SysLib_Delay( 1000) ;

    for(;;)

    {

    Cy_GPIO_Inv( KIT_LED1_PORT, KIT_LED1_PIN ) ;

    printf( "Message #%d\r\n", ++count ) ;

    Cy_SysLib_Delay( 1000) ;

    }

}

========================

The result was

lab2_teraterm.JPG

Finally we do have the precocious messages.

And when I resumed the execution, I could see normal message print outs.

lab2_continued.JPG

As my conclusion, I think that there are "at least" two start up time for the MCU before the debugger takes control.

IMHO, In general, it won't cause harm, but if you can not put up with it,

adding a delay in the beginning of the program may take care of the problem.

moto

View solution in original post

3 Replies
AnkitaS_51
Employee
Employee
100 likes received 50 likes received 25 likes received

Hello,

I am able to reproduce the phenomenon as stated by you.

If you change the code  in main.c from:

printf("x = %d\r\n", x++);

  Cy_SysLib_Delay( 1000 );

to

Cy_SysLib_Delay( 1000 );

printf("x = %d\r\n", x++);

Then this double printing of printf will not occur.

Thanks,

Ankita

MotooTanaka
Level 9
Level 9
Distributor - Marubun (Japan)
First comment on blog Beta tester First comment on KBA

Hi,

I think that I've seen similar symptoms with other IDEs, including PSoC Creator.

This time at first I wondered why two printf()s are generating same result,

as count is being incremented.

Anyway, as I have not used ModusToolBox for a while,

I took advantage of this topic for my rehabilitation of MTW 😉

I used PioneerKitApp from code example.

I modified main.c as follows

===================

#include "cycfg.h"

#include "cycfg_capsense.h"

#include "stdio.h"

int main(void)

{

int count = 0 ;

cy_stc_scb_uart_context_t uart_context ;

    /* Set up the device based on configurator selections */

    init_cycfg_all();

    __enable_irq();

    Cy_SCB_UART_Init( KIT_UART_HW, &KIT_UART_config, &uart_context ) ;

    Cy_SCB_UART_Enable( KIT_UART_HW ) ;

    for(;;)

    {

    Cy_GPIO_Inv( KIT_LED1_PORT, KIT_LED1_PIN ) ;

    printf( "Message #%d\r\n", ++count ) ;

    Cy_SysLib_Delay( 1000) ;

    }

}

===================

The result was just like yours, but as it had "++count" the number was 1.

lab0_teraterm.JPG

Here, as we see the same number again,

I assumed that the program was executed twice

before the debugger finally took control of the MCU.

So to test it, I modified main.c as below.

I added "ModusToolBox Test" message before the loop, so that I could tell

if the loop was executed twice, or whole program was started twice.

==========================

#include "cy_device_headers.h"

#include "cycfg.h"

#include "cycfg_capsense.h"

#include "stdio.h"

int main(void)

{

int count = 0 ;

cy_stc_scb_uart_context_t uart_context ;

    /* Set up the device based on configurator selections */

    init_cycfg_all();

    __enable_irq();

    Cy_SCB_UART_Init( KIT_UART_HW, &KIT_UART_config, &uart_context ) ;

    Cy_SCB_UART_Enable( KIT_UART_HW ) ;

    printf("ModusToolBox Test %s %s\n\r", __DATE__, __TIME__) ;

    for(;;)

    {

        Cy_GPIO_Inv( KIT_LED1_PORT, KIT_LED1_PIN ) ;

        printf( "Message #%d\r\n", ++count ) ;

        Cy_SysLib_Delay( 1000) ;

    }

}

==========================

The result was

lab1_teraterm.JPG

Apparently the initial part and the beginning of the main loop was executed twice.

I think that the time took before the debugger was long enough to allow the MCU free run up to that point,

meantime it was executed twice, I imagine that  "power on" or "write flash complete" and "reset" from the debugger

cause two start ups for the MCU.

So I modified main.c as below.

I added "1 sec" delay before the main loop which contains the "printf()"

========================

#include "cy_device_headers.h"

#include "cycfg.h"

#include "cycfg_capsense.h"

#include "stdio.h"

int main(void)

{

int count = 0 ;

cy_stc_scb_uart_context_t uart_context ;

    /* Set up the device based on configurator selections */

    init_cycfg_all();

    __enable_irq();

    Cy_SCB_UART_Init( KIT_UART_HW, &KIT_UART_config, &uart_context ) ;

    Cy_SCB_UART_Enable( KIT_UART_HW ) ;

    Cy_SysLib_Delay( 1000) ;

    for(;;)

    {

    Cy_GPIO_Inv( KIT_LED1_PORT, KIT_LED1_PIN ) ;

    printf( "Message #%d\r\n", ++count ) ;

    Cy_SysLib_Delay( 1000) ;

    }

}

========================

The result was

lab2_teraterm.JPG

Finally we do have the precocious messages.

And when I resumed the execution, I could see normal message print outs.

lab2_continued.JPG

As my conclusion, I think that there are "at least" two start up time for the MCU before the debugger takes control.

IMHO, In general, it won't cause harm, but if you can not put up with it,

adding a delay in the beginning of the program may take care of the problem.

moto

RiKw_4278376
Level 2
Level 2
5 replies posted 5 questions asked First question asked

Thank you Ankita and Moto for your replies. As both of you suggest, I inserted a delay before printf() is printed the first time in the loop.  It turns out in my case that 200 milliseconds was adequate.  That is,

Cy_SysLib_Delay( 200 );

    for(;;)

    {

        printf("x = %d\r\n", x++);

        Cy_SysLib_Delay( 1000 );

    }

When I remove the 200 ms delay, the problem returns when the debugger stops in main().  But if I press the reset button on the board (PSOC 6 BLE Pioneer Board), the output starts with "x = 0" and continues normally from there; the double printf() does not happen. At that point, it seems to simply be executing the program already loaded into flash.

(BTW, my code is based on the training video, "Welcome to Modus Toolbox; #4 Program & Debug", about 2 min 7 sec into the video, where Alan Hawse puts the printf() before the delay.  Presumably, at one point, this problem did not exist?)

Thanks again.  Off to more creative coding...

--Rick

0 Likes