cancel
Showing results for 
Search instead for 
Did you mean: 

USB Superspeed Peripherals

nipo_3090066
New Contributor II

Hi,

I try to use JTAG to do on-line update of FX3 firmware (to ram directly).

For this, I have working implementations, both with custom and with OpenOCD.

Both implementations are doing the same thing: stop ARM926, reboot the System (to get to a known state), load binary to relevant places, set firmware entry point in memory at 0x40000000, trigger a reboot to get OTP rom code do platform initialization and jump back to the firmware.

Both implementations run fine, most of the time. But sometimes, it happens that FX3 gets unresponsive, both from USB (not enumerated) and from JTAG (does not react to TLR and chain discovery).

For instance, this happens when running OpenOCD with the following script in a loop:

source [find mem_helper.tcl]
source [find interface/ftdi/digilent_jtag_hs3.cfg]

reset_config trst_only

adapter speed 5000

jtag newtap fx3 cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id 0x07926069

target create fx3.cpu arm926ejs -endian little -chain-position fx3.cpu
fx3.cpu configure -work-area-phys 0x4003f000 -work-area-size 0x1000 -event "reset-assert" { }

init

arm7_9 dcc_downloads enable
arm7_9 fast_memory_access enable

echo "Halting target"
halt
soft_reset_halt

echo "Putting target in SVC mode"
reg cpsr 0xd3

echo "Enabling TCMs"
arm mcr 15 0 9 1 1 0x00000015
arm mcr 15 0 9 1 0 0xf0000019

echo "Setting oscillator parameters"
mww 0xE0052000 0x00080015

echo "Masking IRQs"
mww 0xfffff014 0xffffffff

echo "Loading firmware"
mww 0x40000000 0x00000000 3072
load_image firmware.elf 0 elf

echo "Jumping back to ROM, entry=0x40012b28"
# Firmware entry point, for boot rom
mww 0x40000000 0x40012b28

# Shell code that basically triggers a reset through GCTL_CONTROL
mww 0x40000004 0xe59f0018
mww 0x40000008 0xe5901000
mww 0x4000000c 0xe59f2014
mww 0x40000010 0xe1c11002
mww 0x40000014 0xe59f2010
mww 0x40000018 0xe1811002
mww 0x4000001c 0xe5801000
mww 0x40000020 0xeafffffd
mww 0x40000024 0xe0050000
mww 0x40000028 0x40000007
mww 0x4000002c 0x20000001
reg pc 0x40000004
resume

irscan fx3.cpu 4
runtest 10

shutdown

After some successful iterations giving out:

Open On-Chip Debugger 0.10.0+dev-01411-g051e80812-dirty (2020-09-30-16:01)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
Info : clock speed 5000 kHz
Info : JTAG tap: fx3.cpu tap/device found: 0x07926069 (mfg: 0x034 (Cypress), part: 0x7926, ver: 0x0)
Info : Embedded ICE version 6
Info : fx3.cpu: hardware has 2 breakpoint/watchpoint units
Info : starting gdb server for fx3.cpu on 3333
Info : Listening on port 3333 for gdb connections
Halting target
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x60000013 pc: 0x40012cf0
MMU: enabled, D-Cache: enabled, I-Cache: enabled
requesting target halt and executing a soft reset
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x600000d3 pc: 0x00000000
MMU: disabled, D-Cache: disabled, I-Cache: disabled
Putting target in SVC mode
Enabling TCMs
Setting oscillator parameters
Masking IRQs
Loading firmware
Jumping back to ROM, entry=0x40012b28
shutdown command invoked

 I get to a point where chain enumeration is broken (basically, FX3 does not drive TDO any more):

Open On-Chip Debugger 0.10.0+dev-01411-g051e80812-dirty (2020-09-30-16:01)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
Info : clock speed 5000 kHz
Info : JTAG tap: fx3.cpu tap/device found: 0xffffffff (mfg: 0x7ff (<invalid>), part: 0xffff, ver: 0xf)
Warn : JTAG tap: fx3.cpu UNEXPECTED: 0xffffffff (mfg: 0x7ff (<invalid>), part: 0xffff, ver: 0xf)
Error: JTAG tap: fx3.cpu expected 1 of 1: 0x07926069 (mfg: 0x034 (Cypress), part: 0x7926, ver: 0x0)
Error: Trying to use configured scan chain anyway...
Error: fx3.cpu: IR capture error; saw 0x0f not 0x01
Warn : Bypassing JTAG setup events due to errors
Info : Embedded ICE version 15
Error: unknown EmbeddedICE version (comms ctrl: 0xffffffff)
Info : fx3.cpu: hardware has 2 breakpoint/watchpoint units
Warn : WARNING: unknown debug reason: 0xf
Warn : ThumbEE -- incomplete support
Info : starting gdb server for fx3.cpu on 3333
Info : Listening on port 3333 for gdb connections
Halting target
requesting target halt and executing a soft reset
Error: Jazelle state handling is BROKEN!
target halted in Jazelle state due to debug-request, current mode: Supervisor
cpsr: 0xffffffd3 pc: 0x00000000
MMU: disabled, D-Cache: disabled, I-Cache: disabled
Putting target in SVC mode
Enabling TCMs
Setting oscillator parameters
Masking IRQs
Loading firmware
Warn : WARNING: unknown debug reason: 0xf
Warn : ThumbEE -- incomplete support
Error: timed out while waiting for target debug-running
Warn : WARNING: unknown debug reason: 0xf
Warn : ThumbEE -- incomplete support
Error: timed out while waiting for target debug-running
Warn : WARNING: unknown debug reason: 0xf
Warn : ThumbEE -- incomplete support
Error: timed out while waiting for target debug-running
Warn : WARNING: unknown debug reason: 0xf
Warn : ThumbEE -- incomplete support
Error: timed out while waiting for target debug-running
Jumping back to ROM, entry=0x40012b28
Error: unhandled core state

 

The only thing that gets it back to a functional state is to cycle power. Sometimes, toggling reset pin also gets it out of limbo, but not always. I cannot rely on reset pin.

Now the questions:

  1. Is this a known defect ?
  2. Supposedly, JTAG should have precedence on reset pin, not the other way around, is this a known issue ?
  3. Is there a known sequence that is known to produce stable results, i.e. something that can be run in a loop without getting to an unrecoverable state at some point ?

I could not find reference of 1. in public documentation or errata, I could not find reference code for 3.

As an illustration of 2., FX3 JTAG TAP does not answer when reset pin (not trst) is asserted, while TAP should still answer in such cases.

Thanks

0 Likes
5 Replies
AliAsgar
Moderator
Moderator

Hi,

The JTAG debugger on the FX3 is only used for firmware debugging specifically. Kindly look into this KBA.

Best Regards,

AliAsgar

0 Likes
nipo_3090066
New Contributor II

Hi,

Please not I never mentioned boundary scan. This issue is unrelated to boundary scan.

Regards.

0 Likes
AliAsgar
Moderator
Moderator

Hi,

1. Could you specify which JTAG adapter is being used.                                                                             

2. Could you share the schematics of the board.

3. It would be helpful if the complete config file is shared.

4. Also, could you power cycle the board and try again.

Best Regards,                                                                                                                                                                                 AliAsgar                                                                    

 

0 Likes
nipo_3090066
New Contributor II

Hi,

1: JTAG-HS3 from digilent, but I had same results with J-Link or any other probe. This is not a signaling issue.
2: No. It is proprietary information. Is there anything specific I should look for ?
3: Complete config file is in orginal post.
4: Of course, as I said in original post, power cycling or pin reset recovers the chip state. That's not the point.

Since first post, I made other tests. With JLink software stack, I get to the same results. Here is the JLink script I used:

h
wreg cpsr 0x600000d3
wce 0 9 1 1 0x00000015
wce 0 9 1 0 0xf0000019
w4 0xE0052000 0x00080015
w4 0xfffff014 0xffffffff

loadfile firmware.hex 0

w4 0x40000000 0x40011b40
setpc 0xf0000000
g
q 0

 If run in a loop, after some iterations, fx3 will be stuck in some unrecoverable state and its TAP wont answer any more. Pin reset or power cycle manage to get out of this state.

 

Another thing I did was to script power cycling and USB attachment in a way to guarantee full PoR at each iteration. I erased boot EEPROM so that FX3 enumerates from its own boot ROM. At each iteration, I try to load a firmware through JTAG. First JTAG enumeration after PoR, target attachment and firmware upload to RAM goes fine all the time. Then 94 times out of 100 tries, jumping to firmware ended up in a working state. 6 other times,  FX3 crashed irremediably with killed TAP access. Same firmware loaded from bootloader USB API behaves as expected 100%.

This tells me that loading a firmware from JTAG and making boot ROM jump to it randomly crashes the FX3. If there is an actual random crash on JTAG load, this may have been hidden by debug software that basically do reset-and-retry when they loose target.

I admit problem may be in the way I initialize the CPU/Platform before jumping to firmware, but I cannot debug it as I loose debugger connection when this happens.

Then my question again: is there a specific instruction sequence, memory initialization or whatever to implement in order to load any firmware through JTAG and run it reliably ? I could not find any such thing in docs.

Thanks

0 Likes
AliAsgar
Moderator
Moderator

Hello,

Sorry for the delay in response.

When OpenOCD is used, the following commands are to be executed for the FX3 device:

# Set the processor to SVC mode
monitor reg cpsr 0xd3
# Disable all interrupts
monitor mww 0xFFFFF014 0xFFFFFFFF
# Enable the TCMs
monitor mww 0x40000000 0xE3A00015
monitor mww 0x40000004 0xEE090F31
monitor mww 0x40000008 0xE240024F
monitor mww 0x4000000C 0xEE090F11
# Change the FX3 SYSCLK setting based on
# input clock frequency. Update with
# correct value from list below.
# Clock input is 19.2 MHz: Value = 0x00080015
# Clock input is 26.0 MHz: Value = 0x00080010
# Clock input is 38.4 MHz: Value = 0x00080115
# Clock input is 52.0 MHz: Value = 0x00080110
monitor mww 0xE0052000 0x00080015
# Set the PC to 0x40000000
monitor reg pc 0x40000000
si
si
si
si
load
# Set the PC to the entry address
monitor reg pc
continue

Could you confirm if USB Serial is being used for JTAG?

Best Regards,
AliAsgar

0 Likes