cannot get printf on console (STM32F401RE with cube package)

[ckim]

Posted on November 29, 2015 at 16:08

Hello, I'm new to STM32 eval board and I tried to test uart printf example that came with STM32cubeF4 package. The example uses hal driver I understand.

Has anybody succeeded in getting print on console (COM16 port in my case) with that example? I'm using ARM-MDK and when I build-all I get no warning and no error but I see this red x mark on main.c. (see below)

 

when I place the mouse point on the 'X' mark, I see

''error in include chain (cmsis_armcc.h) : expected identifier or '(' ''

What is this error? I guess maybe this is related to my problem.

Best regards,

Chan

[dman]

Posted on November 29, 2015 at 18:54

Hi,

Did you try to re-build the project using STM32CubeMX program?Thanks

[ckim]

Posted on November 30, 2015 at 08:13@narsutis.dainiusok, thanks. I downloaded this ST32cubeMX and created a new project for the same board. Now it doesn't have this #include ''main.h''. and just compiles OK(with no user code stuff in it). So I copy-pasted some codes from the original UART_printf project, added some HAL .c files and fixed stm32fxx_hal_conf.h file to uncomment #define HAL_xxx_MODULE_ENABLED lines. Then the compile was ok this time without the red 'x' mark. But when I debug it, it is the same. The yellow arrow and light blue arrow is pointing HAL_init() line. When I keep pressing F10 it proceeds to the printf statement but cannot cross the line. I don't see any print on the console(tera-term. COM16) terminal. Can you help me more? There must be something I forgot to set.Thanks, regards, (I learned things about the tool in the mean time.. :))Chan

[ckim]

Posted on November 30, 2015 at 12:14

I think the fputc retargetting is correctly done to use UART port.

My question now is : for STM32F401, the printf is set to use USART pins(PA2 and PA3 on the STM32F401). Then where do we set STM32F103CBT6 chip to use USART port (PA2 and PA3) and use USB for PC connection?

Could anybody please give me a tip?

[ckim]

Posted on December 02, 2015 at 06:26

Hope someone give me an advice.

I'm now trying with the original uVision project that came with STM32cubeF4 package.(just added a include path to remove red 'x' in #include line). It compiles ok. When I press Ctrl-F4, the debugger is waiting at the first line of main() because the 'run to main' option is on in the debugger setting. But when I press F5 (run), it doesn't proceed past HAL_init() which is the first line in main(). The assembly instr is ''BL.W HAL_Init''. The LD1 LED on the board keeps blinkig (switching between red and green). The image is shown below. Somebody please help with this, I'm a newcomer into ARM, STM32 and I think many will experience the same thing like me. Maybe the debugger setting of uVision can be wrong. Thanks!(I include the main.c : uart print using HAL driver.

http://pastebin.com/ty7hcEMS

)

[Tesla DeLorean]

Posted on December 02, 2015 at 17:38

If you stop the debugger where is the code stuck?

Can you use the USART independently of the hosting for printf(), putchar(), etc? I've demonstrated the USART on the Nucleo boards with the SPL, I'm afraid I can't help you with the HAL/Cube stuff. No special changes were required to the boards. For SWV output you might want to double check the solder bridges. Make sure you have the most recent drivers and firmware from either ST, or on the mbed site. With the F4 part you're using you'd want to double check the generated code for the clocks, making sure the part is only clocking at 84 MHz, and the flash wait states are set suitably. APB1 should be at 42 MHz, APB2 at 84 MHz

[ckim]

Posted on December 03, 2015 at 02:17

Hi, clive1,

when I press stop, the code is found stuck at while(1) {} statement meaning it passed the printf statement. (I'm not used to uVision, I thought the yellow arrow would change its location realtime but now I realized it shows the location only when it is stopped. thanks). I once checked the board solder bridge is correct - the output of F401 chip uart port is connected to that of F103(for ST-LINV). I hope to hear from someone who's tested uart_printf using HAL drivers. (the project is in the STM32cubeF4 package, I'm using MDK-ARM project.  BTW, ..\..\..\..\..\..\Drivers\CMSIS\Include should be added to the include path.)

[Tesla DeLorean]

Posted on December 03, 2015 at 02:52

Are you sure it's not the Hard Fault while(1) ?

Keil will plough off there if the retargetting isn't handled properly. The symptom is it just disappears from normal code execution, and sits looping in the handler until you stop it. You could use a simple string output to the USART there to test that.[DEAD LINK /public/STe2ecommunities/mcu/Lists/STM32Discovery/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/STM32Discovery/USART%20example%20code%20for%20Nucleo%20F401RE&FolderCTID=0x01200200770978C69A1141439FE559EB459D75800084C20D8867EAD444A5987D47BE638E0F&currentviews=1839]https://my.st.com/public/STe2ecommunities/mcu/Lists/STM32Discovery/Flat.aspx?RootFolder=%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2FSTM32Discovery%2FUSART%20example%20code%20for%20Nucleo%20F401RE&FolderCTID=0x01200200770978C69A1141439FE559EB459D75800084C20D8867EAD444A5987D47BE638E0F¤tviews=1839[DEAD LINK /public/STe2ecommunities/mcu/Lists/STM32Discovery/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/STM32Discovery/USART%20to%20printf&FolderCTID=0x01200200770978C69A1141439FE559EB459D75800084C20D8867EAD444A5987D47BE638E0F&currentviews=2226]https://my.st.com/public/STe2ecommunities/mcu/Lists/STM32Discovery/Flat.aspx?RootFolder=%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2FSTM32Discovery%2FUSART%20to%20printf&FolderCTID=0x01200200770978C69A1141439FE559EB459D75800084C20D8867EAD444A5987D47BE638E0F¤tviews=2226

[ckim]

Posted on December 03, 2015 at 03:55

Hi clive1,

The while(1) {} was not hard fault while statement. It was after the printf.I captured the UART signal from F401RE to ST-LINK chip(F103CB). I used printf(''CCCC''); ascii 'C' is 0x43. I can see 0x43 is transmitted 4 times correctly. And the baudrate seems to be 9600bps. Then the problem is then between ST-LINK chip and my PC. Maybe I'm missing something in uVision debugger setting or so..ADD : when I set 8 bit data, it includes the parity bit, so the picture seems correct. In other direction, I can see when I press my keyboard, the correct value is seen at UART2's DR register(I used peripheral view window). This means PC->STM32F103->STM32F401 is ok. I guess the STM32F401->STM32F103 path has certain error. I now have some questions. 1. How do I set STM32F103's parity bit? Is it set to EVEN parity by default? 2. Or If I set my COM port in the PC's device manager, does it set STM32F103 chip's uart interface?  and What affects serial port setting in the Teraterm?(I saw I can set serial port separately, for teraterm and for device manager COM port). 3. Is there any way I can monitor how the STM32F103 chip UART is receiving data from STM32F401?I hope somebody could clarify this to me. Thanks! (my portable oscilloscope that I borrowed from nearby team is out of battery so I cannot see the waveform right now).

[ckim]

Posted on December 04, 2015 at 13:03Is there any method to check UART receiving status of STM32F103 chip of the STM32F401RE board?