MCU/Arduino RESET - c

I have below setup. I found that My arduino Getting restarted again. I have Arduino board , lCD Display, SENSOR. The Sensor and LCD Display SHARE common ground and 5v supply from 7805 IC and Arduino board get powered on using 7812 regulator IC . finally they are under common ground potential.Now i have Peice of code. Individually i tried each function are working fine without any error and Arduino Board will not get reseted.When i put together all my code block. getting restarted. Once it restart work fine for couple of minute and again reseted.
How to resolve this issue?
#include <LiquidCrystal.h>
#include <avr/wdt.h>
LiquidCrystal lcd(12, 11, 7, 6, 5, 4);
void setup()
{
Serial.begin(9600);
wdt_enable(WDTO_8S);
MODE=INIT;
pinMode(beeper, OUTPUT);
lcdClear();
}
void loop()
{
Track_loop();
LCD_Display();
CHK_Key();
wdt_reset();
Serial.println("..........................");
}
void Track_loop()
{
calcPos();
calcTime();
calcElevationAngle();
callMode();
actuate();
// checkHWFaults();
Wind_calc();
Print_Result();
}
void Print_Result()
{
Print_Date();
Print_Time();
}
I have added these function in my Serial.println statement
void Print_Date(){
Serial.print("Local Date:");
Serial.print(local_day);
Serial.print("/");
Serial.print(local_month);
Serial.print("/");
Serial.println(local_year);
}
void Print_Time()
{ Serial.print("local_time is:");
Serial.print(local_h);
Serial.print("-");
Serial.print(local_m);
Serial.print("-");
Serial.println(local_s);
}

I suspect your use of the Watchdog is causing issues.
If we say that http://www.embedds.com/using-watchdog-timer-in-your-projects/ is an "authoritive" source of information, then maybe your call to wdt_reset() is not being called in time and therefore your system is being reset?
If you enabled watchdog timer, you have to take care and reset it
before it fills up and resets MCU. Otherwise if your program hangs or
sticks in some infinite loop without reset watchdog simply counts up
and resets system
From http://www.nongnu.org/avr-libc/user-manual/group_avr_watchdog.html
#define wdt_reset() __asm__ __volatile__ ("wdr")
Reset the watchdog timer. When the watchdog timer is enabled, a call
to this instruction is required before the timer expires, otherwise a
watchdog-initiated device reset will occur.
If you disable the watchdog from your project, do you still get the same outcome?
Update 1
To debug your code you use the Serial.println("xxxx") function to output the required text to the serial port that you have setup.
See
Google Search
LadyAda Tutorial
Countless others
NOTE: Should we update these instructions so that they contain the full instructions? Marking as Community Wiki so everyone can update as required.

Related

STM32CubeIDE Break at address "xxx" with no debug information available, or outside of program code

I'm busy bring up some new hardware with a STM32F030C8 mcu. I'm using the STM32CubeIDE with gcc. I'm very new to microcontroller development and this is my first project with ST and their tools.
This is a very basic program that just triggers a GPIO. The rest is all generated code. As I have very little experience in this field I hope somebody can point to a location where I can look. I suspect that it might be a configuration issue.
Here is the code (I removed all generated comments to keep it a bit more compact):
int main(void)
{
HAL_Init();
SystemClock_Config();
MX_GPIO_Init();
HAL_GPIO_TogglePin(GPIOB, GPIO_PIN_2); //my code 1
HAL_GPIO_TogglePin(GPIOB, GPIO_PIN_2); //my code 2
while (1)
{
HAL_GPIO_TogglePin(GPIOB, GPIO_PIN_2);
HAL_Delay(1000);
}
}
When I step through the code It will trigger the GPIO on "my code 1" once I step to "my code 2" it will cause the issue. I have even tried just running a fully generated program with no modifications and the issue persists. This was a quick test to see if the program actually does run on the mcu. And it does, as well as trigger the GPIO.
Debugger console Output:
Temporary breakpoint 1, main () at ../Core/Src/main.c:74
74 HAL_Init();
Program received signal SIGTRAP, Trace/breakpoint trap.
0x1fffecec in ?? ()
The Temporary breakpoint is where the program starts, I can then either run from there. Or step through, all with the same result.
Console Output:
Waiting for debugger connection...
Debugger connected
-------------------------------------------------------------------
STM32CubeProgrammer v2.4.0
-------------------------------------------------------------------
ST-LINK SN : 34FF6E065250343816210143
ST-LINK FW : V2J36S7
Voltage : 3.22V
SWD freq : 4000 KHz
Connect mode: Under Reset
Reset mode : Hardware reset
Device ID : 0x440
Device name : STM32F05x/F030x8
Flash size : 64 KBytes
Device type : MCU
Device CPU : Cortex-M0
Memory Programming ...
Opening and parsing file: ST-LINK_GDB_server_PEkdAh.srec
File : ST-LINK_GDB_server_PEkdAh.srec
Size : 4944 Bytes
Address : 0x08000000
Erasing memory corresponding to segment 0:
Erasing internal memory sectors [0 4]
Download in Progress:
File download complete
Time elapsed during download operation: 00:00:00.627
Verifying ...
Download verified successfully
Full Error:
Break at address "0x1fffecec" with no debug information available, or outside of program code.
Here is two images that might help. As I mention I'm very new to this. So any other information required please ask. Thanks in advance.
Debug View
Disassembly
The code is placed at 0x08000000. There is no user code at 0x1fffecec. It system area and probably it boots the system bootloader. It shows that the BOOTx pin is incorrectly connected.

STM32 USB VCP (Virtual Com Port)

I generated a code for "stm32f103c8t6" with CubeMX for USB VCP, when I add "CDC_Transmit_FS" command to send data, the port isn't recognized by windows10!
what should I do? Here is the code which is compiled without error:
#include "stm32f1xx_hal.h"
#include "usb_device.h"
#include "usbd_cdc_if.h"
int main(void)
{
uint8_t Text[] = "Hello\r\n";
while (1)
{
CDC_Transmit_FS(Text,6); /*when commented the port is recognized*/
HAL_Delay(1000);
}
}
There are three things you need to check in my experience:
startup_stm32f405xx.s --> Increase the Heap size. I use heap size 800 and stack size 800 as well.
usbd_cdc_if.c --> APP_RX_DATA_SIZE 64 and APP_TX_DATA_SIZE 64
usbd_cdc_if.c --> add below code to the CDC_Control_FS() function
Code:
case CDC_SET_LINE_CODING:
tempbuf[0]=pbuf[0];
tempbuf[1]=pbuf[1];
tempbuf[2]=pbuf[2];
tempbuf[3]=pbuf[3];
tempbuf[4]=pbuf[4];
tempbuf[5]=pbuf[5];
tempbuf[6]=pbuf[6];
break;
case CDC_GET_LINE_CODING:
pbuf[0]=tempbuf[0];
pbuf[1]=tempbuf[1];
pbuf[2]=tempbuf[2];
pbuf[3]=tempbuf[3];
pbuf[4]=tempbuf[4];
pbuf[5]=tempbuf[5];
pbuf[6]=tempbuf[6];
break;
and define the uint8_t tempbuf[7]; in the user private_variables section.
Without the increased heap size, Windows does not react at all.
Without the point 3, Windows will send the baud rate information and then read the baud rate, expecting to get back the same values. Since you do not return any values, the virtual com port remains as driver-not-loaded.
If you do all of that, the Windows 10 out-of-the-box VCP driver can be used. No need to install the very old ST VCP driver on your system.
PS: I read somewhere turning on VSense makes problems, too. Don't know, I have not configured it and all works like a charm.
Put delay before CDC_Transmit_FS call - it will wait for the initiatialization. Your code should be like this
int main(void)
{
uint8_t Text[] = "Hello\r\n";
HAL_Delay(1000);
while (1)
{
CDC_Transmit_FS(Text,6); /*when commented the port is recognized*/
HAL_Delay(1000);
}
}
I had similar issue. I couldn't connect to a port and the port appears as just "virtual com port". I added while loop to wait for USBD_OK from CDC_Transmit_FS. Then it stars work even with out it or a delay after init function. I am not sure what the issue was.
while(CDC_Transmit_FS((uint8_t*)txBuf, strlen(txBuf))!=USBD_OK)
{
}
you may have to install driver to get device recognized as com port
you can get it from st site
if not installed the device is listed with question or exclamation mark on device manager
note that you cannot send until device get connected to host!
not sure that CubeMX CDC_Transmit_FS is checking for this
also instead of delay to resend you shall check the CDC class data "TXSstate"
is 0 mean tx is over.
I know it's a bit late, but I stumbled upon this post and it was extremely helpful.
Here is what I needed to do:
do the Line-Coding (I think only necessary on Windows-Systems)
increase Heap (Stack was left at default 0x200)
Here is what wasn't necessary for me (on a STM32F405RGT6 Chip):
change APP_RX_DATA_SIZE / APP_TX_DATA_SIZE (left it at 2048)
add a delay befor running CDC_Tranmit_FS()
Also some things to consider that happened to me in the past:
be sure to use a USB-Cable with data lines (most charging-cables don't have them)
double check the traces/connections if you use a custom board

at91sam7 dont work after system reboot. how to force a restart?

I am using at91sam7s64 header board in my project and everything works fine i use usb port to read and write data from micro controller . but when the windows or Linux get reboot or waked up after a standby the device don't work anymore and i have to disconnect/connect the device from USB port. on windows i,m using hidapi library to comunicate with device.
is there any way to force at91sam7s to restart itself in this situation with watchdog or any other way?
upade
I run my code from Flash NOT RAM. It seems that "Windows have two USB reset types inside. A soft reset is just reset signaling on the bus. It resets communication pipes, but drivers already loaded remain active. A hard reset will build up the whole driver tree on top of the device. On the device side you cant see any difference"
Will it work without USB connected at the first place (if you can power the board somehow)? Try to exclude the theoretical assumption that a firmware on your board has an active communication with host operating system at your PC during the work which could lead to embedded system hang/crash when you disconnect the USB cable.
Just be clear (and better include it here in question) that you run the code from flash and not from RAM by, say, emulator from IDE.
Also you can try debugging with JTAG (if you have one) and breakpoint to illuminate the piece of code that stops an execution. The same you can try to find out with printing to some ports (like serials).
I solved this problem with watchdog codes from makecontroller
solution:
watchdogEnable(2000); // start the countdown
void MyTask()
{
while (1) {
if (everything_is_normal()) {
watchdogReset();
}
else {
// if things are not normal, the timer is not reset and will eventually expire
}
}
}
files:
watchdog.c
#include "config.h"
#ifdef WATCHDOG_ENABLE
#include "watchdog.h"
#include "at91sam7.h"
#define WATCHDOG_KEY (0xA5 << 24)
/**
\defgroup Watchdog
The Watchdog timer resets the board in the event that it's not behaving as expected.
This is more robust than using other kinds of timers, because in the worst case, when
your app has malfunctioned, it can still reset since it's not relying on your app to
actually be running.
\section Usage
The watchdog is disabled by default. If you want to make use of it, add the following
line to your config.h file: \code #define WATCHDOG_ENABLE \endcode
If you want to use it, specify the length of the countdown to watchdogEnable() and then
periodically call watchdogReset() to reset the countdown. If the countdown ever gets
all the way to zero, the board will reset.
\b Example
\code
watchdogEnable(2000); // start the countdown
void MyTask()
{
while (1) {
if (everything_is_normal()) {
watchdogReset();
}
else {
// if things are not normal, the timer is not reset and will eventually expire
}
}
}
\endcode
\ingroup Core
#{
*/
/**
Enable the watchdog timer.
Specify the number of milliseconds that the watchdog should wait before
resetting. Remember that watchdogEnable() or watchdogDisable() can only be called
once until the processor is reset again.
The maximum countdown length is 16 seconds (16000 ms).
#param millis The number of milliseconds in which a reset will occur.
*/
void watchdogEnable(int millis)
{
int period = (millis * 256) / 1000;
AT91C_BASE_WDTC->WDTC_WDMR = AT91C_WDTC_WDRSTEN | // enable reset on timeout
AT91C_WDTC_WDDBGHLT | // respect debug mode
AT91C_WDTC_WDIDLEHLT | // respect idle mode
((period << 16 ) & AT91C_WDTC_WDD) | // delta is as wide as the period, so we can restart anytime
(period & AT91C_WDTC_WDV); // set the period
}
/**
Reset the watchdog timer countdown.
Call watchdogEnable() first, and then call this occasionally to reset
the watchdog countdown so that it doesn't expire.
*/
void watchdogReset()
{
AT91C_BASE_WDTC->WDTC_WDCR = WATCHDOG_KEY | AT91C_WDTC_WDRSTT;
}
/**
Disable the watchdog timer.
Turn the watchdog off completely if you don't need it.
If \b WATCHDOG_ENABLE is not defined in your config.h, this is done automatically.
*/
void watchdogDisable()
{
AT91C_BASE_WDTC->WDTC_WDMR = AT91C_WDTC_WDDIS;
}
/** #}
*/
#endif // WATCHDOG_ENABLE
watchdog.h
#ifndef WATCHDOG_H
#define WATCHDOG_H
#ifdef __cplusplus
extern "C" {
#endif
void watchdogEnable(int millis);
void watchdogReset(void);
void watchdogDisable(void);
#ifdef __cplusplus
}
#endif
#endif // WATCHDOG_H

Serial port not sending data

Yesterday, I started with some serial port communication. Today, I tried to open exactly the same sketch I used yesterday. It worked, but a few minutes later when I uploaded it again, it doesn't work at all.
Here's the code:
#include "Blink_main.h"
int pin = 1;
void pulsePin(int abc, int length){
digitalWrite(abc, true);
delay(length);
digitalWrite(abc, false);
}
void setup() {
pinMode(pin, OUTPUT);
Serial.begin(9600);
Serial.println("Hi serial!");
pulsePin(pin, 1000);
}
void loop() {
if(Serial.available() > 0){
Serial.println(Serial.read());
pulsePin(pin, 1000);
}
}
When opening the application, I don't see the "Hi serial!" message, When sending something, I don't get a message back and I don't see the LED flashing. Why is this happening?
You are using pin 1 to blink the led, move the led to another pin since it is used as the serial TX
Digital Pins 0-1/Serial In/Out - TX/RX - These pins cannot be used for digital i/o (digitalRead and digitalWrite) if you are also using serial communication (e.g. Serial.begin).
It look like the problem come from the Arduino board.
Firstly, try to upload a Serial example sketch.
If it doesn't work, try to reinstall the driver or change the COM port used.
If the problem is still happening, it's probably the ATMEGA8U2 or ATMEGA16U2 which is dead. You can test with an external USB to UART convert directly on pins 0 and 1

Program halts while sending byte to USB-to-Prallel (D-Sub 25pins) port

I have an USB to 25-pin parallel port cable. I connected it to laptop and get a port at /dev/usb/lp0, then I connect pin1/pin25 of parallel port with +/- LED it lights.
Now I move +pin of LED to pin 2 of parallel port, and try to send byte to port , it should light up but it doesn't. following is my c code in linux.
#include<stdlib.h>
#include<stdio.h>
#include<sys/io.h>
void main(void)
{
int port=0x378;
outb(0xff,port);
outb(0x01,port+2);
sleep(1);
outb(0x00,port+2);
printf("‌​End");
}
this is my complete program, I also checked it with port=0x3bc but did not work. Even I checked strobe pin 1 by connecting + of LED, it alsways lights but does not go low. May be there is problem with port address.
for /dev/usb/lp0 I also used command line command like $echo $'\xFF' > /dev/usb/lp0 I observed that it does something but does not light up the LED. When I connect LED with pin2 and 25 as + and -. I can see a very little light in side the LED in the beginning but when I run above command that very tiny light disappears but LED does not glow high like it does when I connect it with strobe pin. Also I can only execute above command only two times. Third and later times I thing command does not work while it seems halted.
Can any one help why it halts or how can I get LED switch on/off on data pins? Thanks

Resources