This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Programming multiple ADuC7xxx evaluation boards

Hi all,

My group is using two separate ADuC7026 evaluation boards for a project. Each board is running separate code and hardware. I am attempting to program both using the same laptop, currently running the Keil uVision 4.72 IDE (lite version). My current JLink driver is V4.80c.

Board #1 was my original platform, and to get Board #2 working, I needed to use the ARMWSD tool to mass erase/ program compiled code to Board #2 via UART. After this fix, I am currently able to program Board #2 using uVision with no problem.

However, now when I attempt to program Board #1 in the IDE, the code compiles as usual, but I get the following error stream immediately upon attempting to flash to memory:

---
Device = ADuC7026
Info: Device "ADUC7026X62" selected (62 KB flash, 8 KB RAM).
VTarget = 3.332V
Info: TotalIRLen = 4, IRPrint = 0x01
***JLink Error: Bad JTAG communication: Write to IR: Expected 0x1, got 0x3 (TAP Command : 12) @ Off 0xD4.
Info: Failed to read memory before ADI software reset.
***JLink Error: Bad JTAG communication: Write to IR: Expected 0x1, got 0x7 (TAP Command : 2) @ Off 0x5.
DLL version V4.80c, compiled Jan 21 2014 20:01:42
Firmware: J-Link ARM V8 compiled Nov 25 2013 19:20:08
Hardware: V8.00
Info: Failed to halt CPU core before ADI software reset.
JTAG speed: 750 kHz
Full Chip Erase Failed!
Cannot read memory
***JLink Error: Bad JTAG communication: Write to IR: Expected 0x1, got 0xF (TAP Command : 15) @ Off 0x5.

---

On successive attempts to reprogram Board #1, I get the following errors:

---
Device = ADuC7026
Info: Device "ADUC7026X62" selected (62 KB flash, 8 KB RAM).
VTarget = 3.325V
Info: Could not measure total IR len. TDO is constant high.
Info: Could not measure total IR len. TDO is constant high.
Info: Could not measure total IR len. TDO is constant high.
Info: Could not measure total IR len. TDO is constant high.
DLL version V4.80c, compiled Jan 21 2014 20:01:42
Firmware: J-Link ARM V8 compiled Nov 25 2013 19:20:08
Hardware: V8.00
Info: Could not measure total IR len. TDO is constant high.
Info: Could not measure total IR len. TDO is constant high.
Hardware-Breakpoints: 0
Software-Breakpoints: 0
Watchpoints: 0
Info: Could not measure total IR len. TDO is constant high.
Invalid core Id. (0x00000000)
Trying to connect with 5 kHz !
Info: Could not measure total IR len. TDO is constant high.
Invalid core Id. (0x00000000)

---

Attempts to use the ARMWSD tool on Board #1 have been unsuccessful. I had working code on Board #1 before beginning to work on Board #2, but Board #1 no longer works ever since I've successfully programmed Board #2. The Board #1 code is only approx. 30kB in size.

I am not totally familiar with debug techniques or specifics, so detailed help would be greatly appreciated. Thank you very much for your time!

Parents
  • Hi Weston,

    Thanks very much for the reply!

    Turns out your hint to about looking at how the boards were different was able to solve my problem.

    For posterity -- a few of the on-board demo switches (S1, see Analog Devices AN-744) were selectively switched on Board #1, whereas Board #2 had all of S1 in the off position. Switching Board #1 to match Board #2 eliminated my problems... for some reason.

    Some members of my group are saying that digital lines, if not changed over a long time, can build up a signal over time (eg. via RF? static?) which could pull various pins high/low incorrectly? Any other theories about why this would have fixed my problems?

    I feel a bit silly that this turned out to be the problem. I will have to quietly ask around for the person that was messing with the on-board switches. Will update if anything other problems between the two boards pop up! (A bit nervous to try programming Board #2 immediately after this success, but will do it soon.)

    Again, I appreciate the help, Weston!

Reply
  • Hi Weston,

    Thanks very much for the reply!

    Turns out your hint to about looking at how the boards were different was able to solve my problem.

    For posterity -- a few of the on-board demo switches (S1, see Analog Devices AN-744) were selectively switched on Board #1, whereas Board #2 had all of S1 in the off position. Switching Board #1 to match Board #2 eliminated my problems... for some reason.

    Some members of my group are saying that digital lines, if not changed over a long time, can build up a signal over time (eg. via RF? static?) which could pull various pins high/low incorrectly? Any other theories about why this would have fixed my problems?

    I feel a bit silly that this turned out to be the problem. I will have to quietly ask around for the person that was messing with the on-board switches. Will update if anything other problems between the two boards pop up! (A bit nervous to try programming Board #2 immediately after this success, but will do it soon.)

    Again, I appreciate the help, Weston!

Children