Hi,



I have a target board for a product that has 2 x STM32F103RC micros connected together in a JTAG scan chain. See J-Link Commander output to verify this shows up as 4 JTAG devices correctly:



SEGGER J-Link Commander V4.17a ('?' for help)
Compiled Aug 18 2010 20:00:10
DLL version V4.17a, compiled Aug 18 2010 19:59:54
Firmware: J-Link ARM V8 compiled Aug 12 2010 19:35:38
Hardware: V8.00
S/N : 58003432
Feature(s) : JFlash
VTarget = 3.293V
Info: TotalIRLen = 18, IRPrint = 0x00442211
Info: Found Cortex-M3 r1p1, Little endian.
Info: TPIU fitted.
Info: ETM fitted.
Info: FPUnit: 6 code (BP) slots and 2 literal slots
Found 4 JTAG devices, Total IRLen = 18:
#0 Id: 0x3BA00477, IRLen: 04, IRPrint: 0x1, CoreSight JTAG-DP (ARM)
#1 Id: 0x06414041, IRLen: 05, IRPrint: 0x1, STM32 Boundary Scan
#2 Id: 0x3BA00477, IRLen: 04, IRPrint: 0x1, CoreSight JTAG-DP (ARM)
#3 Id: 0x06414041, IRLen: 05, IRPrint: 0x1, STM32 Boundary Scan
Cortex-M3 identified.
JTAG speed: 100 kHz
J-Link>



I can program firmware into both micros by moving J-Flash ARM settings from
Tap 0, IR len 0 to
Tap 2, IR len 9



I can secure both micros to prevent the code from being read out as well using J-Flash ARM.



This is all good until I then want to reprogram the two micros...



I can only unsecure the first micro on the JTAG scan chain (Tap 0, IR len 0). This causes the device to be erased and can then be reprogrammed.



When I try to unsecure the second micro on the JTAG scan chain (Tap 2, IR len 9), it looks like it works, but the micro remains secured, the code is not erased and the micro cannot be reprogrammed. See following J-Flash output:



Reading entire flash chip ...
- Connecting ...
- Connected successfully
- 128 sectors, 1 range, 0x8000000 - 0x803FFFF
- RAM tested O.K.
- ERROR: Timeout while blank checking, core does not stop
- ERROR: Failed to read back target memory [FAILED Read of a protected chip]
Disconnecting ...
- Disconnected
Unsecure chip ...
- Connecting via USB to J-Link device 0
- Chip unsecured successfully - Completed after 2.284 sec [Seemingly successful unsecure, but chip is still secure...]
Reading selected sectors ...
- Connecting ...
- Connected successfully
- 128 of 128 sectors selected, 1 range, 0x8000000 - 0x803FFFF
- RAM tested O.K.
- ERROR: Timeout while blank checking, core does not stop
- ERROR: Failed to read back target memory [Second FAILED Read of a protected chip (even after a power cycle, it is still secure)]
Disconnecting ...
- Disconnected



I also tried to use the "JLinkSTM32.exe" utility to unlock the micro, but this utility seems to only work on the first device on the JTAG scan chain as it looks to be using SWD rather than JTAG to connect to the micro (and there is no command line options to specify Tap 2, IR len 9, if I wanted to use it to unlock the second micro on the JTAG scan chain anyway...). SWD does not support scanning anything other than the first connected micro so this is not likely to work for my product board anyway.



This problem appears to me to be a bug in the J-Flash ARM software. It may relate to both securing and unsecuring a device at a Tap position greater than 0, I have only shown it to fail when trying the unsecure the device at Tap position 2. I secure the device during programming by writing to the Option Bytes rather than using the "-securechip" command line option.



It would be great if this problem could be diagnosed and possibly fixed as it is causing a fair amount of grief with our product boards that do need to be reprogrammed after being secured from time to time.



Our company has purchased several J-Link ARM devices and we are likely to run into this problem on a number of planned products that use JTAG scan chains to interconnect multiple devices on a single board and JTAG connector.



Thanks,

Nick

Gallagher R&D

New Zealand

Hi,

Just an update to the original problem statement. I still believe that there is a bug in the J-Flash ARM software, but due to the lack of response, it is easier for us to workaround this problem by separating out the JTAG test points on our two micros rather than treating them as a JTAG chain.

Nick