2008-10-11 00:44:52     write/erase flash cause watchdog not working

Document created by Aaronwu Employee on Aug 8, 2013
Version 1Show Document
  • View in full screen mode

2008-10-11 00:44:52     write/erase flash cause watchdog not working

david wang (CHINA)

Message: 63445   

 

hi all,

  My program would write logs to flash when some events occur. But I found once it have operate the flash,

  the watchdog would not able to reset the DSP anymore when some unexpected bug happen. The watchdog just print info, like,

 

  bfin-wdt: Unexpected close, not stopping watchdog!

 

  and the board hang. I cound only reset the power to reboot the system. If I remove all the flash operation, the watchdog

  works fine. I've tried the simple watchdog app, when I andd flash write in the feed procedure, and ctrl+C the program,

  the result is the same to my progrom. My flash is a intel 28f320J3C, and use CFI interface.

 

 

  Is anyone else meet this situation? Is this a bug of the kernel? Thanks !

QuoteReplyEditDelete

 

 

2008-10-11 00:51:14     Re: write/erase flash cause watchdog not working

david wang (CHINA)

Message: 63446   

 

////BELOW IS THE TEST PROGRAM

 

 

 

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

#include <unistd.h>

#include <fcntl.h>

#include <sys/ioctl.h>

#include <linux/types.h>

#include <linux/watchdog.h>

#include <signal.h>

#include <paths.h>

 

#include "../include/watchdogd.h"

 

static char *path = "/dev/mtd3";

static char buf[128];

 

int main(void)

{

int fd, rc, i = 0;

unsigned char sec_num = 5;

Set_Wdog_Timer(&sec_num);

printf("real time is %d \n", sec_num);

while(i++<10000)

{

  sleep(1);

  Feed_Wdog();

 

  {

   if ((fd = open(path, O_TRUNC | O_WRONLY, 0666)) < 0) {

    printf("WARNING: Failed to open file %s\n", path);

    return -1;

   }

   sprintf(buf, "THIS IS A TEST LOG %d\n", i);

#if 1  

   rc = write(fd, buf, strlen(buf));

   if(rc != strlen(buf))

   {

    printf("WARNING: write file failed!\n");

    close(fd);

    break;

   }

#endif  

   printf("\n%d\n", i);

   close(fd);

  }

 

}

 

safe_exit();

return 0;

}

 

//if I move the write section, the watchdog works fine.

 

 

QuoteReplyEditDelete

 

 

2008-10-11 01:50:21     Re: write/erase flash cause watchdog not working

Mike Frysinger (UNITED STATES)

Message: 63447   

 

it means the watchdog daemon was killed.  find out why the daemon was killed.  perhaps you filled up memory and the kernel killed it.

QuoteReplyEditDelete

 

 

2008-10-11 10:07:30     Re: write/erase flash cause watchdog not working

david wang (CHINA)

Message: 63475   

 

Hi, Mike

 

Sorry, I cann't understand what means the watchdog daemon was killed. Isn't the watchdog a hardware function of BLACKFIN DSP? I have thought that once the watchdog starts, it will never stop counting. if the program stop feed the dog within some period, it will reset the core. Am I wrong? If not, How to keep the watchdog daemen live when the program meet a exception? In my demo program, it's very simple,and only if I comment the flash writing operation, everything works fine.

 

 

QuoteReplyEditDelete

 

 

2008-10-11 12:18:03     Re: write/erase flash cause watchdog not working

Mike Frysinger (UNITED STATES)

Message: 63480   

 

the watchdog daemon is not the same thing as the hardware watchdog.  if you get the error message that you did, it means the userspace daemon was killed for some reason.  the hardware watchdog would then reset the system automatically.  if this isnt working properly, it usually means your hardware is not properly designed (missing/not strong enough pullups) wrt the booting source.

 

you need to hook up jtag to find out where exactly the system is hung.

QuoteReplyEditDelete

 

 

2008-10-12 10:03:31     Re: write/erase flash cause watchdog not working

david wang (CHINA)

Message: 63489   

 

Hi, Mike

 

  Thanks for your rapid replies. But I still have some questions. I did want the hardware watchdog reset the system when my program, I think , it is the userspace daemon you called, was killed for some reseon. If our hardware is not properly designed, why it works fine when I remove the flash operation? what pins should pull up, and what should I do to the booting source? Pls tell us more details or reference, thanks a lot!

QuoteReplyEditDelete

 

 

2008-10-12 14:48:07     Re: write/erase flash cause watchdog not working

Mike Frysinger (UNITED STATES)

Message: 63490   

 

you need to finish diagnosing what's going wrong before you attempt to fix anything.  go get a jtag cable.

QuoteReplyEditDelete

 

 

2008-10-12 21:53:43     Re: write/erase flash cause watchdog not working

david wang (CHINA)

Message: 63496   

 

Thanks, I'll try the jtag later.

 

 

QuoteReplyEditDelete

 

 

2008-10-13 00:10:47     Re: write/erase flash cause watchdog not working

david wang (CHINA)

Message: 63506   

 

Hi, Mike

 

  I've used jtag to debug the kernel. Firstly, I'd explain the steps.

 

1) start up my board, load the kernel ,and connect gdbproxy and bfin-elf-gdb.

 

2) start up my test program which is a simple test watchdog , only difference is I add flash operation after each the feed dog

 

3) when the test program running, I input a contrl+C just to kill it and to test if the watchdog could reset the system.

 

4) the gdbproxy print much message of "info:      bfin: [0] core is in idle mode",  but the system not reset.

 

5) I have to contrl+C in the bfin-gdb-elf shell to stop the printing of gdbproxy.

 

Below is the whole info,

 

////////////////////////////  INFO 1, from gdbproxy /////////////////////////

 

[root@localhost gdbproxy]# ./gdbproxy bfin

 

Remote proxy for GDB, v0.7.2, Copyright (C) 1999 Quality Quorum Inc.

MSP430 adaption Copyright (C) 2002 Chris Liechti and Steve Underwood

Blackfin adaption Copyright (C) 2008 Analog Devices, Inc.

 

GDBproxy comes with ABSOLUTELY NO WARRANTY; for details

use `--warranty' option. This is Open Source software. You are

welcome to redistribute it under certain conditions. Use the

'--copying' option for details.

 

Initializing ADI IGLOO JTAG Cable on parallel port at 0x378

IR length: 5

Chain length: 1

Device Id: 00100010011111001000000011001011

  Manufacturer: Analog Devices

  Part:         BF537

  Stepping:     2

  Filename:     /usr/local/share/jtag/analog/bf537/bf537

warning:   bfin: no board selected, BF537 is detected

notice:    gdbproxy: waiting on TCP port 2000

notice:    gdbproxy: connected

info:      bfin: [0] core is in idle mode

notice:    gdbproxy: connected

 

<---------------------------------continue printing when I kill the user space program in the target by ctrl+C

info:      bfin: [0] core is in idle mode

info:      bfin: [0] core is in idle mode

info:      bfin: [0] core is in idle mode

info:      bfin: [0] core is in idle mode

info:      bfin: [0] core is in idle mode

info:      bfin: [0] core is in idle mode

info:      bfin: [0] core is in idle mode

info:      bfin: [0] core is in idle mode

info:      bfin: [0] core is in idle mode

info:      bfin: [0] core is in idle mode

info:      bfin: [0] core is in idle mode

info:      bfin: [0] core is in idle mode

info:      bfin: [0] core is in idle mode

info:      bfin: [0] core is in idle mode

info:      bfin: [0] core is in idle mode

info:      bfin: [0] core is in idle mode

info:      bfin: [0] core is in idle mode

info:      bfin: [0] core is in idle mode

info:      bfin: [0] core is in idle mode

info:      bfin: [0] core is in idle mode

info:      bfin: [0] core is in idle mode

info:      bfin: [0] core is in idle mode

info:      bfin: [0] core is in idle mode

info:      bfin: [0] core is in idle mode

 

<-------------------------when  I input a ctrl+C in the shell of  bfin-elf-gdb, it print below message

 

info:      bfin: [0] EMUIN pin was asserted: PC [0x36D7EE80] FP [0x00292EC0]

error:     bfin: [0] cannot read reserved memory [0x36D7EE7C]

error:     bfin: [0] cannot read reserved memory [0x36D7EE7C]

 

////////////////////////////  INFO 2, from bfin-elf-gdb /////////////////////////

 

[root@localhost images]# bfin-elf-gdb vmlinux

GNU gdb 6.6

Copyright (C) 2006 Free Software Foundation, Inc.

GDB is free software, covered by the GNU General Public License, and you are

welcome to change it and/or distribute copies of it under certain conditions.

Type "show copying" to see the conditions.

There is absolutely no warranty for GDB.  Type "show warranty" for details.

This GDB was configured as "--host=i686-pc-linux-gnu --target=bfin-elf"...

(no debugging symbols found)

(gdb) target remote :2000

Remote debugging using :2000

0xffa0031c in default_idle ()

(gdb) c

Continuing.

 

<------------------nothing happens, when I killed the user space program, until I input a ctrl+C HERE, it print below message

 

Program received signal SIGINT, Interrupt.

0x36d7ee80 in ?? ()

(gdb)

 

 

////////////////////////////  INFO 3 from target/////////////////////////

 

BusyBox v1.4.1 (2008-10-09 16:44:05 CST) Built-in shell (msh)

Enter 'help' for a list of built-in commands.

 

root:/> PHY: 0:00 - Link is Up - 100/Full

 

root:/>

root:/> cd /mnt/bin

root:/mnt/bin> ./wd_test

-->bfin_wdt_ioctl: [c0045706]

-->bfin_wdt_ioctl: [80045707]

real time is 5

-->bfin_wdt_ioctl: [80045705]

MTD_open

MTD_write

MTD_close

-->bfin_wdt_ioctl: [80045705]

 

<-----------------------------------------------------------I input a ctrl+C here to kill the program

-->bfin_wdt_release: in [0]

bfin-wdt: Unexpected close, not stopping watchdog!

root:/mnt/bin>

<------------------------------------------------------------system hang, NOT RESET!

QuoteReplyEditDelete

 

 

2008-10-13 23:16:13     Re: write/erase flash cause watchdog not working

david wang (CHINA)

Message: 63588   

 

HI, all

 

I did other tests and found that even the RAISE 1 instruction can't reboot the system after flash operation.  it could only hang the system but not jump into the u-boot sequence, very like the watchdog situation. But the reboot command did. I guess, it did not clear the REBOOT FLAG in SYSCFG somewhere make the core keep reseting. Is anyone any advise?

QuoteReplyEditDelete

 

 

2008-10-13 23:36:54     Re: write/erase flash cause watchdog not working

Mike Frysinger (UNITED STATES)

Message: 63590   

 

there is no such "REBOOT FLAG" in the SYSCFG register.  i'm guessing you actually mean the NOBOOT bit in the SYSCR register.  however, nothing ever sets that bit.  if your software does, then it's up to you to make sure it is properly handled.

 

however, you should never use "RAISE 1".  that is not safe.  there are safe reset operations already in the kernel that software should always use.

QuoteReplyEditDelete

 

 

2008-10-14 01:54:16     Re: write/erase flash cause watchdog not working

david wang (CHINA)

Message: 63598   

 

  Yes, I mean NOBOOT bit. I use RAISE 1 just to test to find out why it can't reboot the system when it did flash operation.

 

  According to the blackfin document, when the watchdog timer expired, it will cause a WATCHDOG timer reset, which will reset the core and peripherals. Is this procedure done by hardware automaticlly?  if not, what should I do?

QuoteReplyEditDelete

 

 

2008-10-14 02:33:24     Re: write/erase flash cause watchdog not working

Michele d'Amico (ITALY)

Message: 63599   

 

Hi David,

 

Are you using a BF533 Stamp?

 

If it is true, maybe you are playing with a hardware bug related to the CPLD speed. The side effect decribed in https://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdit&tracker_item_id=1296 is little bit different but I don't know the real effect of this bug on your release of u-boot.

 

... if it false please ignore the above message

 

Regards

 

--Michele

QuoteReplyEditDelete

 

 

2008-10-14 02:50:14     Re: write/erase flash cause watchdog not working

Mike Frysinger (UNITED STATES)

Message: 63600   

 

do not use "raise 1".  it is known to randomly hang irregardless of anything else.  any test you try by doing "raise 1" is useless.  i'm not going to say anything more on the topic as it's a waste of time.

 

if the watchdog is configured to reset the part upon expiration, it is done completely in hardware.  however, this doesnt preclude any of my previous statements about hardware and booting sources.  like Michele points out, your hardware needs to make the boot source available fast enough or it will randomly fail.  but this is why you need to debug things completely with jtag to make sure the problem is actually hardware.

QuoteReplyEditDelete

 

 

2008-10-14 03:33:32     Re: write/erase flash cause watchdog not working

david wang (CHINA)

Message: 63604   

 

1 My board is BF537.

 

2 How to debug the boot source with a jtag? Should I put a hardware breakpoint to 0x2000000 and see what happen?

 

 

QuoteReplyEditDelete

 

 

2008-10-14 03:38:35     Re: write/erase flash cause watchdog not working

Mike Frysinger (UNITED STATES)

Message: 63606   

 

the exact proc does not matter.  the issue Michele points out can occur on any processor.

 

setup hardware break points on all system reset locations.  the exact addresses depend on your bootmode.  if you're using bypass, then 0x20000000 would be the logical place to start.

QuoteReplyEditDelete

 

 

2008-10-14 05:22:55     Re: write/erase flash cause watchdog not working

david wang (CHINA)

Message: 63632   

 

Hi, Mike

 

  Thanks! I set a breakpoint at 0x2000000, and then run my test. it 's jump to the breakpoint when the test corrupt. But it did not finish the u-boot. Things is clearer now, at least the watchdog reset the core. I'll check the u-boot later. I read the bf533 watchdog issue thread, I thought maybe the problem is my u-boot version is too old, mine is u-boot.1.1.3.I'll tell you the result later.

 

 

QuoteReplyEditDelete

 

 

2008-10-14 07:41:10     Re: write/erase flash cause watchdog not working

david wang (CHINA)

Message: 63644   

 

Hi, Mike

 

  I set two hardware breakpoints, one is at 0x20000000 and another is at 0x01fc00000, which is u-boot load point in sdram section. when the test corrupt, it can jump to 0x20000000, but can't reach 0x1fc00000. I don't know why?what breakpoint should I set? Thanks!

QuoteReplyEditDelete

 

 

2008-10-14 22:50:33     Re: write/erase flash cause watchdog not working

david wang (CHINA)

Message: 63673   

 

hi, all

 

  After one day's debugging, I thing I have found the problem making the board hang. I put a hardware breakpoint at 0x20000000 and another at 0x20000004. if every thing goes well, each breakpoint should be hit once when the system reboot , just like manual rest in u-boot. In my test, it can only reach the first breakpoint, not the next. I use x command to check the flash, it show me all of 0x00800080, that means the flash is not ready. But, I just find the problem, I don't know why the flash status is not ready, and how to fix it. Does anyone have any idea? Thanks!

QuoteReplyEditDelete

 

 

2008-10-15 03:27:01     Re: write/erase flash cause watchdog not working

david wang (CHINA)

Message: 63677   

 

Hi, Mike

 

  would you pls try my test program -- see attached file, in your stamp board to help me find out it's a hardware or software issue? Thanks a lot!  The only thing you should change is the flash device. In my test , I use dev/mtd3. I have create 8 mtd device in my board.

 

crash_test.c

QuoteReplyEditDelete

 

 

2009-05-14 08:43:03     Re: write/erase flash cause watchdog not working

Servaes Joordens (NETHERLANDS)

Message: 74066   

 

David,

 

Just a thought:

 

On my board (bluetechnix tcm_bf537bp) PF4 and PF5 are used to enable higher data area's in the flash memory map.

Maybe those outputs are still set when a reboot occurs causing the processor to try to boot from a wrong part of the flash memory. You can try clearing those outputs in your test application.

 

regards,

 

Servaes

Attachments

Outcomes