cancel
Showing results for 
Search instead for 
Did you mean: 

A strange problem related to printf by SWO port. Is there two cores in stm32 chip?

zjuniverse
Associate II
Posted on February 25, 2014 at 16:45

I found this problem when debug the CAN bus. The received data can not be showned in the printf via SWO. At first I thought there were something wrong in configuraion. But at last I found that the data can be shown in a LCD screen.

At last I located the problem at the blowing program.

        int i = 0;

        int flag = 0;

        int t = 0;//

        char buf[32];//buffer

        while (1) {

                if (i == 0) {

                        if (flag)//flag is non-zero means a message has been received.

                                sprintf(buf, ''%d\n'', t++);//write t to buf, and ++t.

                        else

                                sprintf(buf, ''a%d\n'', t++);//write t to buf. The 'a' is for distinguishing

                        LCD_Println(0, buf);//show the data in LCD screen

                        printf(buf);//send data to PC via SWO port

                        if(flag){//I didn't write this 3 lines at first, I'll explain this later.

                                while(1);

                        }

                        flag = 0;//clear the flag

                        i = 1000000;//it costs about 1s for i to decreased to zero

                } else if (i > 0) {

                        i--;

                }

                if (CAN_GetFlagStatus(CANx, CAN_FLAG_FMP0)) {//data received

                        LED_Toggle(0);//toggle the led 0

                        flag = 1;

                        t = 0;//reset the variable t

                        CAN_Receive(CANx, CAN_FIFO0, &RxMessage);//receive the data, to clear the FLAG_FMP0

                }

                if (flag)//show the state of flag

                        LED_On(1);

                else

                        LED_Off(1);

        }

When there're no the line 13 to 15, the expected result is that when a message received, the printed number start again from zero. But the real result is that the number on the LCD do what expected, but the data received via SWO just increases, as if no data received by CAN bus.

After adding line 13 to 15, the expected result is that when a message received, the number is set to zero and stop increasing. The real result is that the number on the LCD do stop, but the number received from SWO port just increases as usual.

So It seems there are two core in the chip, and the one that manages the SWO port doesn't know that a message have been received from the CAN BUS.

I use a STM32F407VG, and the debugger is ST-Link on the STM32F4 Discovery board. The compiler I used is GCC.

4 REPLIES 4
zjuniverse
Associate II
Posted on February 25, 2014 at 16:47

Sorry for poor English. Please don't hesitate to ask me about the detail if anything is unclear.

Posted on February 25, 2014 at 16:57

So It seems there are two core in the chip, and the one that manages the SWO port doesn't know that a message have been received from the CAN BUS.

There aren't so ponder other possibilities.

So look at the code doing the character output, if it's looping data, or if the receiving end is looping it.
Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
zjuniverse
Associate II
Posted on February 25, 2014 at 17:41

I write the data to a buffer before sending them to LCD and SWO, so there's only on place that do math operation and it's expected that the data should be the same.

On the other hand, the code sending character is rarely simple, and I use the ST-Link Utility to receive data.

There's just one function as blow:

#ifdef _DEBUG

int _write(int fd, char* ptr, int len)

{

if (fd == STDOUT_FILENO || fd == STDERR_FILENO)

{

int i = 0;

while(i<len)

ITM_SendChar(ptr[i++]);

}

return len;

}

The ITM_SendChar is defined in core_cm4.h .

#endif

zjuniverse
Associate II
Posted on February 26, 2014 at 07:38

Finally I found the problem. It seems there's two cores running and it does! Because I forget to remove the jumper on the discovery board so there are actually two chips running, one on the target board and another one on discovery board. When programming chip, both chips were programmed and the data received from SWO is from the chip on discovery board, which doesn't have hardware related to the CAN bus.