Flash failure for batch of STR731

[m_schubert]

We have a bit of an issue with a batch of STR731FV2T7 microcontrollers (oldschool, I know) not being able to be flashed properly. Any help would be appreciated. We've verified all the usual suspects are not a problem (signal integrity, crystal oscillation, power supply rails all OK). We've also x-ray inspected the packages and the dies, bond wire and package all look the same as known working batches.

Anyway, when we try to flash the board with a SEGGER Flasher, we get the following:

SEGGER J-Link Commander V6.44h (Compiled May 3 2019 17:37:48)
DLL version V6.44h, compiled May 3 2019 17:37:09

Connecting to J-Link via USB...O.K.
Firmware: J-Link ARM / Flasher ARM V4 compiled Apr 18 2019 16:17:53
Hardware version: V4.02
S/N: 164215152
License(s): JFlash, GDB
IP-Addr: 10.0.0.156 (DHCP)
VTref=5.019V


Type "connect" to establish a target connection, '?' for help
J-Link>Please specify device / core. <Default>: STR731FV2
Type '?' for selection dialog
Device>Please specify target interface:
J) JTAG (Default)
TIF>Device position in JTAG chain (IRPre,DRPre) <Default>: -1,-1 => Auto-detect
JTAGConf>Specify target interface speed [kHz]. <Default>: 4000 kHz
Speed>Device "STR731FV2" selected.


Connecting to target via JTAG
Could not measure total IR len. TDO is constant high.
Could not measure total IR len. TDO is constant high.
Could not measure total IR len. TDO is constant high.
Could not measure total IR len. TDO is constant high.
Cannot connect to target.

 I can get the emulator to recognise the microcontroller by either holding it in reset (pulling RST low), or by changing the boot mode to system memory, but in both cases the emulator can't flash or erase anything because it can't halt the CPU:

 SEGGER J-Link Commander V6.44h (Compiled May 3 2019 17:37:48)
DLL version V6.44h, compiled May 3 2019 17:37:09

Connecting to J-Link via USB...O.K.
Firmware: J-Link ARM / Flasher ARM V4 compiled Apr 18 2019 16:17:53
Hardware version: V4.02
S/N: 164215152
License(s): JFlash, GDB
IP-Addr: 10.0.0.156 (DHCP)
VTref=5.024V


Type "connect" to establish a target connection, '?' for help
J-Link>Please specify device / core. <Default>: STR731FV2
Type '?' for selection dialog
Device>Please specify target interface:
J) JTAG (Default)
TIF>Device position in JTAG chain (IRPre,DRPre) <Default>: -1,-1 => Auto-detect
JTAGConf>Specify target interface speed [kHz]. <Default>: 4000 kHz
Speed>Device "STR731FV2" selected.


Connecting to target via JTAG
TotalIRLen = 4, IRPrint = 0x01
JTAG chain detection found 1 devices:
#0 Id: 0x3F0F0F0F, IRLen: 04, ARM7TDMI Core
ARM7 identified.
J-Link>Using DBGRQ to halt CPU
Resetting TRST in order to halt CPU

****** Error: Unable to halt CPU core
Downloading file [C:\firmware\binaries\20200423.hex]...

****** Error: Failed to download RAMCode.
Failed to prepare for programming.
Failed to download RAMCode!
Can not read register 0 (R0) while CPU is running
Can not read register 1 (R1) while CPU is running
Can not read register 2 (R2) while CPU is running
Can not read register 3 (R3) while CPU is running
Can not read register 4 (R4) while CPU is running
Can not read register 5 (R5) while CPU is running
Can not read register 6 (R6) while CPU is running
Can not read register 7 (R7) while CPU is running
Can not read register 10 (R8_USR) while CPU is running
Can not read register 11 (R9_USR) while CPU is running
Can not read register 12 (R10_USR) while CPU is running
Can not read register 13 (R11_USR) while CPU is running
Can not read register 14 (R12_USR) while CPU is running
Can not read register 15 (R13_USR) while CPU is running
Can not read register 16 (R14_USR) while CPU is running
Can not read register 9 (R15 (PC)) while CPU is running
Can not read register 8 (CPSR) while CPU is running
Can not read register 30 (R14_ABT)
Unspecified error -1
J-Link>

 Changing JTAG clock speeds doesn't help, either.

Any ideas? The package markings on the IC show:

STR731FV2T7
Y
22 3VT VG
MLT 22 748

[mƎALLEm · Accepted solution]

Hello @m_schubert and welcome to the ST community.

That's indeed a quite old MCU (STR7xx family) from early 2000's. I don't think there is one here can help you on that issue as most of ST employees worked on that product are retired, left the company or moved to another position.

[Peter BENSCH]

@m_schubert In addition to what @mƎALLEm  said, it should be mentioned that the STR731 has also been obsolete for a long time. This reduces the chance that anyone can help to an extremely low level.

[m_schubert]

Hi folks, understood. It's kind of the reason I've reached out here - we'll have to write off a decent batch of microcontrollers, and they're getting hard to source. Might be time for a redesign...

[mƎALLEm]

---

@m_schubert wrote:

Might be time for a redesign...

---

Indeed.

[mƎALLEm]

@m_schubert 

You can use any of the STM32 MCUs and you will find a good support in this community and we are happy to help you.

If your question has been answered please Accept as Solution one of the provided answers above.

Thank you