cancel
Showing results for 
Search instead for 
Did you mean: 

STM32 application while(1) loop stops after 60 seconds only when UART running

harinath
Associate III
Posted on September 11, 2013 at 15:20

Hello,

I'm developing firmware(FW) for STM32F103RE mcu, an USB & UART bluetooth module (PAN1321i) connected to mcu. Application has 4 working modes. In all the FOUR modes FW supposed to send & receive data to USB or bluetooth or to both. Computer initiates connection to the device via USB virtual COM port or Bluetooth COM port.

1. FW works fine when USB virtual COM port opened in PC.

2. FW does work fine when USB virtual COM port & Bluetooth COM port opened in PC.

3. FW stops executing while(1) loop after 60 seconds when only Bluetooth COM port opened in PC.

4. FW works fine (doesn't sends & receives data if USB or Bluetooth ports are not opened)

In hardware the UART2 of STM32 connected to Bluetooth module. When I open Bluetooth COM port in PC and send some bytes, I can see the data received in USART2 Rx interrupt handler when debugging the FW using breakpoints in IAR EWARM. But the while(1) loop is not running. Now If I open USB virtual COM port, again the FW sends & receives data via Bluetooth. 

Now If I close the USB virtual COM port, again the while(1) loop stops running after 60sec.

What is this behavior ? Is the STM32 going into sleep mode when USB not connected ?

I do not have any code which will place STM32 into sleep mode.

Thanks in advance.

#stm32f103 #time-to-start-debugging #60-seconds #don''t-just-sit-there---debug!
12 REPLIES 12
Posted on September 11, 2013 at 15:35

> FW stops executing while(1) loop

How do you know that?

Jerry Mouse
harinath
Associate III
Posted on September 11, 2013 at 15:38

PC side I have an application which opens USB COM or Bluetooth COM port & display number of data packets received & time also.

jpeacock2399
Associate II
Posted on September 11, 2013 at 15:48

That only tells you the USB stopped responding, not where the error is located.  Sounds like some basic debugging, logging events inside your while event loop to determine the context where the controller program hangs.

  Jack Peacock
Posted on September 11, 2013 at 15:50

That's no proof. The PC app and the BT module could have stopped working too.

Blink a LED.

JW

harinath
Associate III
Posted on September 11, 2013 at 16:29

@Community member

The FW application sends data when only after the PC application Openes USB virtual COM or/and Bluetooth COM ports. When mode 1 and mode 2 are working fine for more than 10 hours properly, why doesn't the mode 3 work ? The described problem is repeatable.

harinath
Associate III
Posted on September 11, 2013 at 16:30

@waclawek.jan

The PC side application & bluetooth modules does not have any problem in communicating with stm32 device. This is true because, The mode 2 works after mode 3.

When I open Bluetooth COM port in PC and send some bytes, I can see the data received in USART2 Rx interrupt handler when debugging the FW using 

breakpoints 

in 

IAR 

EWARM

 for 60 seconds

. But the while(1) loop is not running after that. Now If I open USB virtual COM port, again the FW sends & receives data via Bluetooth & usb both. 

 

Now If I close the USB virtual COM port, again the while(1) loop stops running after 60sec.

This clarifies us that there is not problem in USB as well as Bluetooth link ( bluetooth module & PC side bluetooth dongle are fine).

Posted on September 11, 2013 at 16:40

And the LED stops blinking after 60 seconds?

JW

harinath
Associate III
Posted on September 11, 2013 at 16:43

yes. because the FW while(1) loop is not running.

jj2
Associate II
Posted on September 11, 2013 at 17:06

Two smart, experienced guys have well advised. 

You may save the effort of Led, series R by placing an incrementing variable w/in that ''while.''   Its cessation will confirm your belief.

When both judge & jury - reside same house - drive same car - proper trial unlikely.

Take & apply the advice - then report - unsound ''logic/clinging'' is not your friend...