Forums

Brad-

Aditi Akula

FF8196 a6513805                 MOV port(#03805h),T2
FF819A 7d800066                 AND #32768,T2,T2
FF819E 0406f5                   BCC #0xff8196,T2 == #0

Do you know what is memory-mapped location 0x3805?  Is this the "DSP side" of the HPIC?  According to the data sheet, the HPIC is not visible to the 5510.

-Jeff

Aditi Akula

2)   Also, after halting in the bootloader code, we see that the Bus Error bit is getting set in the STATUS_REG 3 (ST3_55).

Aditi Akula

When we halt, the code does not always halt at the same point and sometimes it halts in memory section 0x8000xxh -

Since both of these issues occur prior to any of your code actually executing I can only imagine there must be some kind of hardware issue (unstable clocks, noisy power supply, not enough power supply decoupling, etc).  This happens even if you don't actually make any HPI accesses right, i.e. I want to make sure the HPI host device is not interfering some how.  For example, the boot ROM itself uses a tiny bit of RAM for the stack.  If the HPI host clobbered that RAM it might cause the CPU to go off into the weeds.  Those details are discussed in the bootloader app note.

Brad-

The 5510A data sheet (SPRS076O) says:

  RST_MODE controls how a device reset is handled.
  As of revision 2.1, the RST_MODE function will no longer be supported. RST_MODE will be
  driven low internally. After reset, the CPU will branch to the reset vector and begin execution.
  The external state of the RST_MODE pin will have no effect on device operation.

Aditi is using C5510A (Rev 2.2) and trying to boot in EHPI mode.  So after power-on if the chip doesn't wait for RESET bit in the HPIC, then it may run uninitialized code.  The data sheet basically implies "EHPI boot mode is no longer supported", although no TI document I can find directly says that.  SPRA741A, Using the TMS320VC5509/5510 Enhanced HPI (2006), still describes EHPI boot mode procedure (bootloader waits for RESET bit, host loads code, sets RESET bit, etc).

What is the work-around for this?  We don't have an option to boot other than EHPI mode.

-Jeff

Aditi Akula

["Compiler" Settings: "Debug"]
Options=-g -fr"$(Proj_dir)\Debug" -d"_DEBUG" -ml -v5510 --symdebug:coff

Assuming that you are using the 5510A (i.e. silicon revision 2.2) then you should use -v5510:2.2 instead of -v5510.  This will generate more efficient code (i.e. get rid of workarounds for bugs present in older revisions), and I've even heard reports of better overall stability.

Aditi Akula

["Compiler" Settings: "Release"]
Options=-fr"$(Proj_dir)\Release"

It looks to me like you're not even using this mode.  You should add -ml and -v5510:2.2 same as your debug, and typically -o2 or -o3 for optimization.

Jeff Brower

Brad-

Aditi Akula

FF8196 a6513805                 MOV port(#03805h),T2
FF819A 7d800066                 AND #32768,T2,T2
FF819E 0406f5                   BCC #0xff8196,T2 == #0

Do you know what is memory-mapped location 0x3805?  Is this the "DSP side" of the HPIC?  According to the data sheet, the HPIC is not visible to the 5510.

-Jeff

 

This is effectively a backdoor method of accessing the HPIC.RESET value.  The ROM code is polling this bit waiting for the host to set HPIC.RESET.

FYI, this is documented in the bootloader app note I mentioned previously.  Here's the snippet:

The general procedure for boot loading using the EHPI is:
• RESET pin is released (low-to-high transition) with BOOTM[3:0] = 1101b.
• The CPU executes the on-chip ROM bootloader and begins to poll the RESET bit in HPIC, to
determine when the host load is complete.
• The host loads the desired code and data sections into DSP internal memory within the
address limits mentioned above.
• The host indicates the load is complete by setting the RESET bit in the HPIC register.
• The CPU transfers execution to byte address 010000h, and the loaded application begins
running.

Jeff Brower

The data sheet basically implies "EHPI boot mode is no longer supported", although no TI document I can find directly says that.  SPRA741A, Using the TMS320VC5509/5510 Enhanced HPI (2006), still describes EHPI boot mode procedure (bootloader waits for RESET bit, host loads code, sets RESET bit, etc).

In Section 3.1.6 "Bootloader" of the data sheet it specifies EHPI boot as an option.  We simply modified the internal mechanism for EHPI boot.  Instead of relying on the RST_MODE capability we now have the bootloader simply poll for HPIC.RESET to be set.

Brad-

HPIC "Ready" bit?   Where is this documented?  We can't find this in any TI documentation.  If this bit is controlled by an external pin or at least one host write to HPIC is required, that might explain why our 5510 module sees an unpredictable value of bit 15 at memory-mapped 0x3805.

-Jeff

Typo, meant to say "RESET" bit.  I corrected my previous post.

Brad-

It's not  RESET (bit 0)  Aditi posted above a code excerpt from the C5510A bootloader showing what it's looking for in HPI boot mode, here it is again:

Aditi Akula:

FF8196 a6513805                 MOV port(#03805h),T2
FF819A 7d800066                 AND #32768,T2,T2
FF819E 0406f5                      BCC #0xff8196,T2 == #0

As noted in the forum discussion above, the bit being polled is 15.  This is not documented.

Can you please give a definitive answer and point out where this is documented.  Also we have a question pending about C5510A bootloader source code.  Can you send that to us?  It's tedious to figure this out using disassembly.  Thanks.

-Jeff

Sorry I cannot share the ROM code.  And yes it is polling the RESET bit.  I have already shared the relevant documentation which states that the ROM code polls HPIC.RESET.  That same bit is mapped elsewhere and it happens to be mapped to bit 15.  This register is not documented as it is not something we want you to use.  I will say no more of this register.  Sorry, but the boot ROM is intended to be a black box and everything you need to know is (should be!) documented in the bootloader app note.

So can you give an update on exactly what you're seeing?  I expect the CPU to sit in that spin loop while you're loading your code and once you set RESET the loop should terminate and the CPU should begin executing from byte address 0x10000 (EHPI word address 0x8000).

• How often do you see issues, i.e. can you not ever boot successfully using HPI or is this 50% of the time, etc?
• How many boards have you tested, i.e. does the issue appear with the same frequency across more than 1 board?
• If your external host does nothing at all do you still see the CPU sitting in this spin loop?
• If your external host does everything except set the RESET bit do you still see the CPU sitting in this loop?
• Upon setting the READY bit do you see the CPU branch to 0x10000?
• Have you built the application such that c_int00 gets linked to address 0x10000?
• Have you tried creating an application (simple one) that runs entirely from internal memory?  Does that work any more reliably?
• In general, how is your stability when running with the emulator?

Brad-

Brad Griffis

Sorry I cannot share the ROM code.

Not asking for all ROM code, just bootloader source.  TI has published bootloader source for various C54x, C55x, and C64x devices many times over the last 15 or so years.  I don't know why this particular device (5510, 9 years old) would be different, especially if it helps customers solve tech issues while asking fewer questions and spending less TI tech support time.  But in any case we'll get the source outside of this forum, so not a problem.

Brad Griffis

And yes it is polling the RESET bit.  I have already shared the relevant documentation which states that the ROM code polls HPIC.RESET.  That same bit is mapped elsewhere and it happens to be mapped to bit 15.  This register is not documented as it is not something we want you to use.  I will say no more of this register.

By adjusting the CCS memory map we can view 0x3805 and we're able to rule out power-on sequence, Reset, clock, or other forms of boot inconsistency (RESET bit is always zero, as expected).  On this thread we posted our power-on sequence, if you want to take a look:

  http://e2e.ti.com/support/dsp/tms320c5000_power-efficient_dsps/f/109/p/74724/273756.aspx#273756

Now we're fairly confident our problem is some slight sensitivity in the JTAG circuitry that only affects breakpoints, but doesn't affect single-step, program download, memory access, register access, etc.  I assume that breakpoints somehow stress the 5510 JTAG circuit a bit more, maybe longer JTAG command sequence or faster burst of timing, not sure.   Do you know if that's the case?

Brad Griffis

Sorry, but the boot ROM is intended to be a black box and everything you need to know is (should be!) documented in the bootloader app note.

Well, that's the point.  The bootloader app note is 2005, older than the other docs.  For example, did you know that IO4 is asserted at the start of *all* boot modes, including HPI?  That's not documented, but it's important because it's an external signal that we can watch on the dig scope, independently of JTAG + CCS.

-Jeff

Jeff Brower

Now we're fairly confident our problem is some slight sensitivity in the JTAG circuitry that only affects breakpoints, but doesn't affect single-step, program download, memory access, register access, etc.  I assume that breakpoints somehow stress the 5510 JTAG circuit a bit more, maybe longer JTAG command sequence or faster burst of timing, not sure.   Do you know if that's the case?

Can you elaborate more on this?  What are the symptoms/behaviors that you are seeing?  Are you setting a hardware breakpoint somewhere in the ROM code or is this a software breakpoint being placed in your code (or a hardware breakpoint being placed on your code)?

Jeff Brower

Well, that's the point.  The bootloader app note is 2005, older than the other docs.  For example, did you know that IO4 is asserted at the start of *all* boot modes, including HPI?  That's not documented, but it's important because it's an external signal that we can watch on the dig scope, independently of JTAG + CCS.

I'm also in favor of having the boot ROM code more broadly available so customers can figure stuff out themselves!  :)  However, I don't get to decide these things!  If you have a local FAE to contact perhaps he can get you the code (or pieces of it).