flash erase errors with aduc7026 (arm7tdmi) based card

Development Boards MicroMod
1

Hi,

I’m having troubles erasing the memory of an aduc7026 (arm7tdmi) based card. The thing is it works about once every 5 attempts (after power-cycling everything).

While the solution to the problem might be simple, but we are beginners with openocd and we have been stuck on it for a few days now.

The error we are getting is:

failed erasing sectors 0 to 123 in procedure ‘flash’

All the details have been enclosed bellow.

Thanks for your time and your help,

Yannick

HARDWARE WE ARE USING:

The card we are using is: Olimex ADUC-P7026

details: https://www.olimex.com/dev/aduc-p7026.html

content of our custom board card config file: board/Olimex_ADuCP7026.cfg

jtag_rclk 10

source [find target/aduc702x.cfg]

reset_config trst_and_srst

the JTAG dongle interface we use is: Olimex ARM-USB-OCD

(interface/olimex-arm-usb-ocd.cfg)

https://www.olimex.com/dev/arm-usb-ocd.html

interface/olimex-arm-usb-ocd.cfg

OPENOCD / LIFBTDI / OPERATING SYSTEM VERSIONS:

OpenOCD 0.6 (current version on git repository)

Libftdi: libftdi-0.20.tar.gz from http://www.intra2net.com

Operating systems (the tools have been installed on 2 different machines):

  • Linux Debian sqeeze on 64bit x86 machine

  • Mac OS X Snow Leopard 10.6.8 on 64bit x86 machine

openocd startup messages:

Open On-Chip Debugger 0.6.0-dev-00640-g40801d2 (2012-08-01-21:09)

Licensed under GNU GPL v2

For bug reports, read

http://openocd.sourceforge.net/doc/doxygen/bugs.html

Info : only one transport option; autoselect ‘jtag’

RCLK - adaptive

adapter_nsrst_delay: 200

jtag_ntrst_delay: 200

trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain

Info : RCLK (adaptive clock speed) not supported - fallback to 10 kHz

Info : JTAG tap: aduc702x.cpu tap/device found: 0x3f0f0f0f (mfg:

0x787, part: 0xf0f0, ver: 0x3)

Info : Embedded ICE version 1

Info : aduc702x.cpu: hardware has 2 breakpoint/watchpoint units

flash information grabbing and failing erasing attempt:

tnx@gozer:pts/3 ~> telnet rhea 4444

Trying 192.168.1.22…

Connected to rhea.

Escape character is ‘^]’.

Open On-Chip Debugger

halt

target state: halted

target halted in ARM state due to debug-request, current mode: Abort

cpsr: 0x600000d7 pc: 0x0000013c

flash banks

#0 : aduc702x.flash (aduc702x) at 0x00080000, size 0x0000f800,

buswidth 0, chipwidth 0

flash list

{name aduc702x base 524288 size 63488 bus_width 0 chip_width 0}

flash probe 0

flash ‘aduc702x’ found at 0x00080000

flash info 0

#0 : aduc702x at 0x00080000, size 0x0000f800, buswidth 0, chipwidth 0

0: 0x00000000 (0x200 0kB) not protected

1: 0x00000200 (0x200 0kB) not protected

2: 0x00000400 (0x200 0kB) not protected

3: 0x00000600 (0x200 0kB) not protected

4: 0x00000800 (0x200 0kB) not protected

5: 0x00000a00 (0x200 0kB) not protected

6: 0x00000c00 (0x200 0kB) not protected

[…]

#118: 0x0000ec00 (0x200 0kB) not protected

#119: 0x0000ee00 (0x200 0kB) not protected

#120: 0x0000f000 (0x200 0kB) not protected

#121: 0x0000f200 (0x200 0kB) not protected

#122: 0x0000f400 (0x200 0kB) not protected

#123: 0x0000f600 (0x200 0kB) not protected

aduc702x flash driver info

flash erase_address 0x00080000 0x0000f800

failed to erase sector at address 0x00080000

failed erasing sectors 0 to 123

in procedure ‘flash’

2

Is it a command we miss to set the tap write-able ?

Do we miss something obvious in the 3 lines board definition file ?

3

Just curious how it behaves if you send the same command immediately after a failure (no reset, etc). Writes to my STM32-based board with OpenOCD and the Olimex arm-usb-ocd seem to fail about 30% of the time on the first try. Since in my case the failure rate is 1% or less on the second try, I’ve not bothered to pursue it.

That rclk looks unusual but I didn’t research it yet.

[edit] Looks like ‘adaptive clocking’ is failing, causing you to fall back to 10KHz, which is really slow. Maybe you’re getting into a timeout issue of some sort.

I’ve never used jtag_rclk, so I’m not sure what to suggest. But…

Try some stuff at random, such as

  • Leaving that statement out and using the defaults

  • Values of 500 or 200 or 100

  • Using adapter_khz rather than jtag_rclk

Waaay back after I first bought this adapter, I struggled for several days to get it to talk to my Olimex LPC2148 board. The solution at that time turned out to be adding jtag_khz 500 to my config files. (later bumped up to 1000).

As openocd has evolved, it appears the default speed is now 1000kHz for the olimex-arm-usb-ocd. I apparently lost my config files with jtag_khz, which is good because the name of that parameter has apparently been changed to adapter_khz

4

Hi Hsutherl,

Thanks a lot to reply to our message!

For your info, jtag_rclk has been renamed to adapter_khz in openocd 0.6.

First of all, to answer you questions:

  • If we repeated the flash erase after a failing attempt, we have the same error message again

  • If we repeat the flash erase after a successful attempt (tried 4 times)

  • we tried to comment jtag_rclk, and tried different values for adapter_khz

  • It looks more likely to succeed if we powercycle the card before doing an attempt

We set adapter_khz to different values and we left it at 10 just to do some testing. We got the erase working a couple of times, unfortunately we are still unable to find the reason why it fails most of the time.

I have a few questions:

  1. you are saying that our rclk looks unusual but to be honest we don’t know what value to give it. How can we find out ?

  2. in which mode does the chip needs to be in to authorize writing, is it supervisor ? abort ?

We are currently doing more tests to try to know more about the conditions in which it succeeds / fails and will keep you posted.

Thanks,

Yannick

edit:

typically here is an example of the messages we are getting when it works:

Open On-Chip Debugger
> init reset
  flash init
init   jtag arp_init
  jtag arp_init-reset
  jtag init   mflash init   nand init noinit   pld init power_restore
reset [run|halt|init]
srst_deasserted
  target init
  transport init in procedure 'init'
> halt
> flash erase_address 0x00080000 0x0000f800
erased address 0x00080000 (length 63488) in 46.754955s (1.326 KiB/s)
> flash erase_address 0x00080000 0x0000f800
erased address 0x00080000 (length 63488) in 46.771065s (1.326 KiB/s)
> flash erase_address 0x00080000 0x0000f800
erased address 0x00080000 (length 63488) in 45.245964s (1.370 KiB/s)
> flash erase_address 0x00080000 0x0000f800
erased address 0x00080000 (length 63488) in 42.799091s (1.449 KiB/s)
> flash write_image /home/minh/Desktop/source_arm7/ADuC7026_minh/blinky.elf 0 elf
can't read "watchdog_hdl": no such variable

wrote 1910 bytes from file /home/minh/Desktop/source_arm7/ADuC7026_minh/blinky.elf in 5.043038s (0.370 KiB/s)
5

Hello Yannick,

I don’t have any more ideas on things to try.

clock speed: I thought you might be having some sort of watchdog timer problem due to the slow clock. It doesn’t appear that this is the case, so 10KHz is probably as good a speed as any until you isolate your problem. I have not looked at the ADuC7206. The datasheet for the LPC2148 only says that the JTAG clock should be less than 1/6 of the core clock.

I thought that abort condition looked a tiny bit suspicious. My (limited) understanding is that in theory, openOCD could set all the core registers to the required state before beginning the flash operation. But in practice I don’t know. You probably already tried reset halt; before the erase command.

Good luck!

-Hugh