- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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:
- Is this a known defect ?
- Supposedly, JTAG should have precedence on reset pin, not the other way around, is this a known issue ?
- 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
Solved! Go to Solution.
- Labels:
-
USB Superspeed Peripherals
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Could you try the cfg script in the attached folder? I tried doing the iterative programming using this cfg script at my end. The issue did not seem to occur. Please try this script at your end and let us know if the issue persists.
Best Regards,
AliAsgar
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
The JTAG debugger on the FX3 is only used for firmware debugging specifically. Kindly look into this KBA.
Best Regards,
AliAsgar
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Please not I never mentioned boundary scan. This issue is unrelated to boundary scan.
Regards.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
"monitor"-prefixed commands are to be used from gdb. I have no gdb in aforementioned setup. Moreover, you'll notice the commands in the original script from first message actually do the exact same thing that you are doing here.
Please also consider the problem I'm raising is not when setuping/loading debug session, but when leaving it and releasing the CPU to run (i.e. somewhere between "resume" and "shutdown" in my original script.
I dont use "USB Serial". As I said before, I tried multiple probes, including JTAG-HS3 from digilent, J-Link, my own, etc.
Regards
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
Could you share the USB trace with us?
Also could you try the exact steps mentioned in section 3.1 of EzUSBSuite_UG available with the SDK and let us know the results.
Best Regards,
AliAsgar
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
As device does not enumerate on USB when it fails, there is no USB trace to share (well, an empty trace is not very informative).
Section 3.1/3.2 assumes I'm running eclipse, which is a non-goal from the start. I'd like to run this in a (headless) automated context, not a debug context.
Let's put this another way:
Could you please provide an openocd script/config that is able to do JTAG-loading of a firmware from an ELF/IMG/HEX file (choice is yours) to RAM of a FX3 (and run it) in a reliable manner, that is usable headless ?
Thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
Even before enumeration, there will be some traffic on the USB lines. Could you provide that?
Kindly refer to the openocd script in the path "C:\Program Files (x86)\Cypress\EZ-USB FX3 SDK\1.3\JTAG\OpenOCD\Windows\openocd" in the EZ-USB FX3 SDK download
Best Regards,
AliAsgar
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
Thanks for you answer.
You probably meant script in C:\Program Files (x86)\Cypress\EZ-USB FX3 SDK\1.3\JTAG\OpenOCD\Config\arm926ejs_fx3.cfg ? It only contains declaration of CPU, but does no loading to RAM. It does not even feature setup of FX3 platform (clock, TCMs, etc.).
Did I miss something ?
Thanks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
Could you explain in detail all the steps to be done to load firmware onto the FX3 using openocd.(Including information about the platforms used at each step) We are trying to reproduce the issue on our side.
Best Regards,
AliAsgar
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I want to load a firmware to a powered fx3 through JTAG (in theory, whatever its state, it may be in bootloader, in a firmware already, I dont really care). Goal is to just load firmware to ram and jump to it. Script does the following in a headless manner:
- Declare adapter configuration (here there is HS3, but any other OpenOCD JTAG adapter will produce the same effect),
- Declare chain,
- "init" will end declarative part and start command session,
- then CPU is initialized, then platform,
- finally code is loaded,
- and I try to reboot CPU/platform to loaded firmware,
- finally, detach from debugger logic in ARM9.
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
In my testing, loaded firmware image is unimportant. This also happens with SDK example firmwares, so I wont provide any firmware image to load. You should replace the occurrences of 0x40012b28 with your actual "firmware.elf" entry point when running this script.
In theory, as there are no preconditions, this OpenOCD session could be run multiple times in a row and get to a running firmware all the time. This is actually not the case. After a random number of times (3-20 in my tests), FX3 will crash so hard it will not even answer to JTAG chain enumeration.
Is there something I missed in initialization or termination of script ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
We tried running your configuration script at our end. But we were faced with some errors during the firmware load stage.
Could you please try running your script on the Superspeed Explorer Kit using USB Serial as JTAG probe and share with us the results?
Best Regards,
AliAsgar
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sorry for the delay, I had to buy a devkit just for you.
Here is an attachment of the same base script adapted for devkit. You'll find reference firmware that I load in FX3 (cyfxslfifosync.elf, straight from SDK). I assume there is no bootloader present if I2C eeprom of devkit.
Run test.sh, wait for it to end.
In attached test log, you'll see it runs 16 times before failing in an unrecoverable manner. On your side, it may take more or less time.
Regards
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
We could reproduce the issue at our end. We are working on it.
Best Regards,
AliAsgar
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
1. Could you try running the attached config script (jtag2.cfg) with the openocd.exe provided with the FX3 SDK and share the output log file with us, if the issue is occurring.
2. Also, are you using a Linux OS or Windows OS for running these tests?
Best Regards,
AliAsgar
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
Thanks for your feedback. If I run jtag2.cfg in a loop on a running FX3, it does not crash JTAG chain. But this does not solve the problem.
My goal here (as stated in the first message of this thread) is to get the platform to a repeatable known state (i.e. whatever the state of the platform/CPU/IPs). Going through boot ROM is helping this in this process. As I understand test2.cfg, you removed the part where FX3 rebooted through boot ROM. I admit this is a smart move, as it is probably the reason for the crash/lockup I'm experiencing. OTOH, it makes the whole thing worthless. Let me explain:
Let's say firmware crashed. JTAG is the only option to recover it, as platform is stuck in an unknown state. Loading with this script should be able to recover the FX3 to a working state even if CPU crashed.
My approach was loading to RAM and letting boot ROM do the reinitialization job. We have no such code any more.
See attached archive:
- crash.elf is a stupid firmware that writes to unmapped memory during startup (just added a write of 32 bits to address 0xdeadbeef in main()).
- cyfxslfifosync.elf is still the same, from SDK,
- test.sh tries to load crash.elf (which should work fine), then tries to load some other firmware (which should work fine as well).
After crash.elf is loaded, CPU is crashed. With test2.cfg, openocd cannot recover the situation and is unable to load cyfxslfifosync.elf.
Side note, I'm a little puzzled by your script, it seems TCM init is not doing what it says, didn't you forget to execute said code after putting it to RAM ?
# Enable the TCMs
echo "enable TCM"
mww 0x40000000 0xE3A00015
mww 0x40000004 0xEE090F31
mww 0x40000008 0xE240024F
mww 0x4000000C 0xEE090F11
At the moment, I'm using MacOS or Linux interchangeably. It is unimportant to me.
Regards
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Sorry for the delay but we are trying to debug at our end. Meanwhile could you help us by answering these questions:
1. Could you explain to me how FX3 gets reset by the shell code in your configuration script?
2. Which openocd.exe is being used? The one provided with the FX3 SDK or the generic one found on the official openocd website?
3. Could you confirm if the same issue is being seen on the Windows OS as well?
Best Regards,
AliAsgar
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
1: python one liner to convert to binary:
open("bla.bin", "wb").write(b''.join(x.to_bytes(4, "little") for x in [0xe59f0018, 0xe5901000, 0xe59f2014, 0xe1c11002, 0xe59f2010, 0xe1811002, 0xe5801000, 0xeafffffd, 0xe0050000, 0x40000007, 0x20000001]))
Then:
$ arm-none-eabi-objdump -b binary -m arm -D bla.bin
bla.bin: file format binary
Disassembly of section .data:
00000000 <.data>:
0: e59f0018 ldr r0, [pc, #24] ; 0x20
4: e5901000 ldr r1, [r0]
8: e59f2014 ldr r2, [pc, #20] ; 0x24
c: e1c11002 bic r1, r1, r2
10: e59f2010 ldr r2, [pc, #16] ; 0x28
14: e1811002 orr r1, r1, r2
18: e5801000 str r1, [r0]
1c: eafffffd b 0x18
20: e0050000 and r0, r5, r0
24: 40000007 andmi r0, r0, r7
28: 20000001 andcs r0, r0, r1
Which is equivalent to:
volatile uint32 *r0 = (volatile uint32_t *)0xe0050000; // GCTL_CONTROL
uint32 r2 = 0x40000007; // GCTL_CPU_RESET_N | GCTL_POR | GCTL_SW_RESET | GCTL_WDT_RESET
uint32 r2_2 = 0x20000001; // GCTL_POR | GCTL_HARD_RESET_N
uint32_t r0 = *r1;
r0 = (r0 & ~r2) | r2_2;
for(;;)
*r0 = r1;
In full text: take GCTL_CONTROL, clear GCTL_CPU_RESET_N, GCTL_POR, GCTL_SW_RESET and GCTL_WDT_RESET set GCTL_POR, GCTL_HARD_RESET_N, write back in a loop until reset is effective.
2: I can reproduce it with any OpenOCD. The one from SDK (MacOS, Linux or Windows), the one from https://github.com/Infineon/openocd/, and the one from Zylin HEAD. Note the same hardware lockup happens with J-Link (using J-Link probe and software), or even with custom JTAG probe and driving software. To me, this is not openocd-related.
3: Yes.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi ,
Could you let us know how you got the register contents at 0xE0050000?
Best Regards,
AliAsgar
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
One more thing I noticed was for the PC relative addresses. For the LDR commands, should it be corrected as follows:
E59F0018 <-> E59F0020
E59F2014<->E59F201C
E59F2010<->E59F2018.
Please try making these changes and let us know if the issue persists.
Best Regards,
AliAsgar
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Thanks for feedback.
So you suggest me to only set GCTL_WARM_BOOT and not POR.
It does not work any better using my example from 2021-09-13-fx3-loader.zip.
But I feel offsets were better before. With latest tweaks, this boils down to:
00000000 <.data>:
0: e59f0020 ldr r0, [pc, #32] ; 0x28
4: e5901000 ldr r1, [r0]
8: e59f201c ldr r2, [pc, #28] ; 0x2c
c: e1c11002 bic r1, r1, r2
10: e59f2018 ldr r2, [pc, #24] ; 0x30
14: e1811002 orr r1, r1, r2
18: e5801000 str r1, [r0]
1c: eafffffd b 0x18
20: e0050000 and r0, r5, r0
24: 40000007 andmi r0, r0, r7
28: 20000000 andcs r0, r0, r0
There is no chance it does what it should: It loads from wrong offsets.
Remember ARM PC-relative loads use instruction PC + 8 as reference (DDI0100I, page A5-20).
But if I put back offsets as they should, It does not work either. FX3 still does not recover from crash situation.
Regards
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Yes, POR corresponds to hard reset and that particular bitfield in the GCTL register can only be set by hardware, and not by software.
Yes, you were right about the PC relative addresses.
We will try to look more into the issue.
Best Regards,
AliAsgar
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Could you modify the configuration script so as to perform a Hard Reset and let us know if the issue still occurs? This will help us narrow down the cause of the problem.
You could just comment the line mww 0x40000018 0xE1811002 in your configuration script.
Best Regards,
AliAsgar
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sorry, but commenting write to 0x40000018 makes no sense. Not writing memory and then executing it will basically execute whatever sits there. Results will not be reliable.
I made extra effort to be able to reproduce everything with devkit and sdk binaries, in order for you to test it on your end. Even if I could be a remote-execution peon, I feel this is really suboptimal.
Moreover, I expect you have access to boot ROM source code, chip RTL simulation models, and that you are able to do lower-level debugging that I can do.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
You could try putting the code below for performing hard reset:
mww 0x40000004 0xE59F0018
mww 0x40000008 0xE5901000
mww 0x4000000C 0xE59F2014
mww 0x40000010 0xE1C11002
mww 0x40000014 0xE59F2010
mww 0x40000018 0xE5801000
mww 0x4000001C 0xEAFFFFFD
mww 0x40000020 0x00000000
mww 0x40000024 0xE0050000
mww 0x40000028 0x40000007
mww 0x4000002C 0x20000000.
Please let us know if the issue persists.
Best Regards,
AliAsgar
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Any updates?
Best Regards,
AliAsgar
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It produces the same results as before. It does not work.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Any news ?
Regards,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I am really sorry for the delay in the response. I was caught up a bit somewhere else.
I will discuss this issue internally and let you know as soon as possible.
Best Regards,
AliAsgar
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
Proposed script does not jump to loaded firmware after loading. It is not doing expected work.
Regards.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Could you probe the JTAG signals using a logic analyser or an oscilloscope and let us know the difference in the signals during a working and a failure condition.
Best Regards,
AliAsgar
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Please retrieve trace {e53e8a0e-1c7e-4b03-8259-08a0186e8f5d} from Ellisys Type-C Tracker software (340 MB). Both USB and JTAG are probed.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Please tell us how should we retrieve traces pointed by you.
Best Regards,
AliAsgar
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I could successfully retrieve the traces from cloud.
Please ignore the previous post.
Best Regards,
AliAsgar
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content