I have a setup with two C6678 devices connected by hyperlink, DSP0 and DSP1. DSP0 is also connected via PCIe to a linux system. Both DSPs have jtag access, and I can load and debug them via jtag. I also have a PCIe based loader which can load programs directly on DSP0. I am running the hyplnk_exampleProject which comes with the PDK, which utilizes the hyperlink LLD. I can run this example fine via jtag, however when I run this program via the PCIe loader, the core hangs (I am told so when I attempt to attach via jtag). In both cases I am *not* using a gel file to initialize anything. Also, interestingly enough, if I load the program via PCIe, but don't start it, then connect via jtag and start the loaded program, things work fine too. This tells me that the loader is working correctly.
Any ideas? I know this is a shot in the dark.
Can you clarify what you mean by core hangs when you use the PCIe loader? You say you're told so when you attempt to attach via JTAG. What specifically are you told?
Please click the Verify Answer button on this post if it answers your question.
By 'hung' I mean that I receive the following error when trying to connect to the core in CCS via JTAG:
Error connecting to the target:
(Error -1143 @ 0x0)Device core was hung. The debugger has forced the device to a ready state and recovered debug control, but your application's state is now corrupt. You should have limited access to memory and registers, but you may need to reset the device to debug further.(Emulation package 5.0.623.0)
Let me give you some additional information: I have my CCS project, which produces a .out file which can be loaded and run via JTAG. I also take this .out file and produce a 'firmware image' suitable for loading via PCIe. Early on in main() I place the following code:
volatile int foo = 1;
This allows me to spin until I manually change the value of 'foo' to zero from with CCS (via JTAG debugging).
I have 3 cases:
1) I run this program via JTAG, suspend, set foo to zero, resume. Everything works fine.
2) I run this program via PCIe loading. Then I connect via JTAG, and suspend. the program is spinning on 'foo'. I set foo to zero, resume, and everything works fine.
3) I recompile with 'foo' hardcoded to zero. PCIe load/run. Connect via JTAG and I get the "core hung" message.
So, I know from this experiment (and from successfully loading and running other programs) that the PCIe loader is loading segments correctly and starting execution correctly. In fact, if I pause the program early enough, then connect via JTAG and allow the rest of the program to run while JTAG is connected, everything works fine.
Any ideas? I really appreciate the help with this one, as I know that there are a lot of variables & things that could be wrong.
Can you dump the register's, including the PC. Also, can you find out what code is at the location of PC when it's 'hung'?
Core Registers PC 0x00809F44 Core Register CLK 0x00000000 Core Register SP 0x0080C8D0 Core Register FP 0x0080C8D0 Core Register A0 0x0080C96C Core Register A1 0x00000001 Core Register A2 0x00000000 Core Register A3 0x00002004 Core Register A4 0x21400080 Core Register A5 0x00000000 Core Register A6 0x0080C8F8 Core Register A7 0x00000000 Core Register A8 0x00000000 Core Register A9 0x00000007 Core Register A10 0x01000104 Core Register A11 0x0081BB04 Core Register A12 0x00504074 Core Register A13 0x00873700 Core Register A14 0x00873680 Core Register A15 0x008734A8 Core Register A16 0x0080C96C Core Register A17 0x00000000 Core Register A18 0x0080C8F8 Core Register A19 0x0080C8F8 Core Register A20 0x21400080 Core Register A21 0x00000001 Core Register A22 0x50180B20 Core Register A23 0x0080140C Core Register A24 0x0009240C Core Register A25 0x0306A009 Core Register A26 0x00000001 Core Register A27 0x00000000 Core Register A28 0x00000000 Core Register A29 0x00000000 Core Register A30 0x00000001 Core Register A31 0x00000001 Core Register B0 0x00000001 Core Register B1 0x00000000 Core Register B2 0x008014F0 Core Register B3 0x008028C4 Core Register B4 0x0080C96C Core Register B5 0x00000000 Core Register B6 0x0080C968 Core Register B7 0x00000004 Core Register B8 0x0080C6D8 Core Register B9 0x0000003A Core Register B10 0x0D104048 Core Register B11 0x41448240 Core Register B12 0x54880006 Core Register B13 0x22008200 Core Register B14 0x0080F880 Core Register B15 0x0080C8D0 Core Register B16 0x00000030 Core Register B17 0x0080C964 Core Register B18 0x0080DC08 Core Register B19 0x00000000 Core Register B20 0x04821674 Core Register B21 0xC009C00C Core Register B22 0xA0041583 Core Register B23 0x00000000 Core Register B24 0x00000000 Core Register B25 0x66B2129F Core Register B26 0x34415603 Core Register B27 0x08594D04 Core Register B28 0x40000101 Core Register B29 0x70134143 Core Register B30 0x00000015 Core Register B31 0xFFFFFFFF Core Register ERP 0x00000000 Core Register: Exception return pointer ARP 0x00000000 Core Register: Analysis return pointer DIER 0x00000000 Core Register: Debug interrupt enable register ETSR 0x00000000 Core Register: Exception TSR snapshot _RESV 0000000000000000 Reserved IB 0 Interrupts blocked SPLX 0 SPLOOP Executing _RESV 000 Reserved EXC 0 Execption Processing INT 0 Interrupt Processing _RESV 0 Reserved CXM 00 Current Execution Mode _RESV 0 Reserved DBGM 0 Emulator debug mask XEN 0 Maskable exception enable GEE 0 Globale exception enable SGIE 0 Saved global interrupt enable GIE 0 Global interrupt enable
This is on Core0:
Spectrum Digital XDS560V2 STM TRAVELER Emulator_0/C66xx_0 (Suspended) hyplnk_read_status_reg(struct CSL_VusrRegs *, struct hyplnkStatusReg_s *)() 0x00809F44 (hyplnk_read_status_reg has only skeletal debug info)
So it appears that it is in hyplnk_read_status_reg(), which is a function in the hyperlink LLD I believe.
ControlRegisters AMR 0x00000000 Core Register: Addressing mode register CSR 0x15000101 Core Register: Control status register GFPGFR 0x0700001D Core Register: Galois field multiply control register ICR 0x00000000 Core Register: Interrupt clear Register IER 0x00000013 Core Register: Interrupt enable Register IFR 0x00000000 Core Register: Interrupt Flag Register IRP 0x00000000 Core Register: Interrupt return pointer ISR 0x00000000 Core Register: Interrupt Set Register ISTP 0x0080F000 Core Register: Interrupt service table pointer NRP 0x00000000 Core Register: Non maskable interrupt PCE1 0x00809F44 Core Register: Program counter E1 phase DNUM 0x00000000 Core Register: DSP Number ECR 0x00000000 Core Register: Exception clear register EFR 0x00000000 Core Register: Exception Flag Register GPLYA 0x00000000 Core Register: GMPY polynomial for A-side GPLYB 0x00000000 Core Register: GMPY polynomial for B-side IERR 0x00000000 Core Register: Internal exception cause register ILC 0x00000000 Core Register: Inner loop SPL buffer count ITSR 0x00000000 Core Register: Interrupt task state register NTSR 0x00000000 Core Register: Non maskable TSR snapshot REP 0x00000000 Core Register: Restricted Entry Point Register RILC 0x00000000 Core Register: Reload Inner loop SPL buffer count SSR 0x00000000 Core Register: Saturation status register TSCH 0x24022D72 Core Register: High half of 64-bit timestamp TSCL 0x7ED7E3E2 Core Register: Low half of 64-bit timestamp TSR 0x00000001 Core Register: Task state register FADCR 0x00000000 Core Register: Floating Point Register FAUCR 0x00000000 Core Register: Floating Point Register FMCR 0x00000000 Core Register: Floating Point Register
Here are the control registers, maybe they're helpful too?
Thanks for the dump, I'm going to ask a colleague to take a look at this who's a bit more familiar w/ the CCS connection.
I don't think the device is actually hung, but instead running in a tight loop w/ interrupts off and CCS can't break the loop and halt the device. So from CCS perspective it appears hung.
Hopefully my colleague can be able to provide more details, and verify or debunk my comment.
I have a question related to this issue: Hyperlink has two sides (local and remote), and the hyperlink peripheral has access to to remote side's registers as well. This can be used to configure both sides address translation units. Is it also possible (and advisable) to reset the remote side peripheral using the remote registers, or will that cause problems?
In other words, can I assert and deassert reset on the remote side's hyperlink peripheral? Or will remote register access not work correctly when the remote side is in reset?
The 'hang' seems to be related to the hyperlink configuration on DSP1 (the DSP without PCIe connected). Currently I have it booting IBL from EEPROM. IBL then does the PLL work-around, and then sets DEVSTAT bootmode bits to 'hyperlink boot', and jumps back in to the RBL. This does indeed enable the hyperlink powerdomain and clocking, but something seems to go wrong because the following happens every time:
1) Boot DSP1 (RBL->IBL->RBL)
2) connect via JTAG to DSP1
3) view memory at 0x21400000 (hyperlink config) -> JTAG reports:
C66xx_0: Trouble Reading Memory Block at 0x21400000 on Page 0 of Length 0x100: (Error -1178 @ 0x21400080) Device functional clock appears to be off. Power-cycle the board. If error persists, confirm configuration and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 5.0.623.0)
After that JTAG has problems doing anything -> something is messed up in HW/emulation
All this occurs without running anything on DSP0. If I remove some jumpers to set DSP0 to "no boot" mode, then initialize hyperlink peripheral via a JTAG loaded program, everything works fine.
So something about the RBL hyperlink boot mode configuration step is screwing the hardware up.
As a workaround, I can probably either code hyperlink initialization in to IBL itself, or have IBL load a hyperlink initialization program from EEPROM, and never re-enter the RBL.
It would be nice to have hyperlink fully setup by RBL though, as we intend to eliminate the EEPROM once IBL is no longer needed for the PLL work-around.
My problem definitely seems like it is caused by the configuration of the hyperlink peripheral on my DSP1. I have triple checked the value of DEVSTAT that I am writing within IBL before jumping back to RBL, and it should correctly configure hyperlink according to my refClk (312.5Mhz). I have also verified that I get the same behavior if I ignore IBL and attempt to boot straight from RBL (ie set the bootmode pins to hyperlink boot instead of I2C boot).
I have a couple questions:
1) Can anyone comment and confirm that they have succeeded in getting a C6678 to hyperlink boot, using RBL to configure the hyperlink?
2) Any ideas what could be causing the hyperlink peripheral to "lock up"?
Remote register area access by CCS memory window without real connection to the remote VUSR can cause DSP 'hang'
you can block the remote register memory area by editing memory access map in the GEL file or using other way.
When you reset remote VUSR by setting remote access register, you should wait until the reset procedure is finished before you access it again.
Yes, I discovered the 'hang' caused by viewing remote registers when the connection is not ready. I noticed that the EVM's gel file mentions this and configures the memory map to not display the remote configuration registers by default.
You mention that "When you reset remote VUSR by setting remote access register, you should wait until the reset procedure is finished before you access it again." Can you expand on that? I take it to mean that it is possible to remotely reset the HL peripheral. But resetting the peripheral involves asserting and then deasserting the 'reset' bit in the control register, correct? How is the remote side brought out of reset, if one cannot access the control register to deassert 'reset'?
Yes. you are correct and I misunderstood about reset procedure.
So it is not good to try to reset remote device by setting remote registers.
The HyperLink User Guide makes several mentions of potential problems concerning reset. I believe that the hang I am experiencing is related to these. I have found that I can eliminate the hang I am talking about by placing several pauses (spinning on the timestamp counter for a while) during the reset/configuration of the peripheral. This provides a work-around for me, but I'm not happy that I don't understand what is going on, and I am not convinced the problem is completely gone. Could someone please post the series of register writes/reads to take to correctly place hyperlink in reset, configure the peripheral, and bring it out of reset? I'm particularly interested in when and where to set the serial_stop bit, and how to determine when it is safe to reset the peripheral.
unfortunately, we couldn't have chace to think about that kind of stable procedure for reset.
each customer experiece slightly different problem, so it is not easy to make general recommandation.
I think we need to think about that for the next design. I may join our internal discussion later and wiil talk about this issue.
Sorry to give you incovinience about reset.
Well, when is it necessary to reset the peripheral?
For my application, I don't necessarily ever need to reset the hyperlink peripheral, if I can just get it configured and working once, that would be enough. The problem is that the hyperlink LLD example resets the peripheral (actually it writes 'reset' twice) during the configuration of the peripheral:
The first time is in the function hyplnkExampleSysSetup (void), somewhere around line 710 the following line occurs:
this happens right after the hyperlink power domain is turned on.
After this reset write, the VUSR PLL and serdes configuration are written.
Then later, in the function hyplnkExamplePeriphSetup (void), reset is again asserted (even though it is already in reset), and then de-asserted to bring the peripheral out of reset.
If find that if I configure the peripheral (by which I mean: enable the power domain, configure PLL, configure SERDES, apply powermanagement,wait for link...) without ever writing reset to the device, then I also experience a hang.
So, I actually don't care too much about resetting the peripheral, if I can just get it configured correctly once.
Can you give me the appropriate register write/read sequence for that? Including enabling the powerdomain, configuring PLL and serdes settings, waiting for PLL lock, etc...
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.