C5509A core suspend(or Crash) problem(use HPI multiplexed boot)

JianJun,

Did you use TI documents in designing your system?
  SPRA375F: Usinng Bootloader (available here - http://focus.ti.com/lit/an/spra375f/spra375f.pdf)
  SPRAA30:  HW Designer's Resource Guide (available here - http://focus.ti.com/lit/an/spraa30/spraa30.pdf)

What are you using for the Host to load program into C5509A internal DARAM?
What memory location are you loading your program to?  HPI has limited access to DARAM (1st 4 blocks)
Can you use emulator to load .out file directly to DSP DARAM and run successfully?

 

TommyG,

Thanks for your rapid reply.

I have read all documents to check my design,and checked my hardware design pin by pin,and I can't find any mistake.

I use a FPGA soft core(NIOS II)  as the HOST,It's not a problem,As mentioned before,the HOST can communicate with DSP by HPI very stablely.

(the hardware is upgraded from C5416,the C5416 boot and run is very stable).

I load my program to program byte address 0x4000 by HPI.When the DSP fail to boot,I use emulator to inspect the dsp data memory address 0x60 and 0x61,

it's content is 0xff00,0x4000. And I also disassambly and check the code at 0x4000,It just looks correct.(I tried many times,the result is same.)

When the DSP fail to boot,I connect the emulator,and I can load .out file to DSP DARAM normal,but the strange thing is: when the emulator try  to set the PC to program entry point(0x4000),It fails every time.

The css GUI looks like follow:

 

I select 'cancel', and Inspect the cpu register,GUI looks like:

It seems correct,I try to run,a error  "Can't Run Target CPU:Processor communication timeout " occurs.

And I quit CCS then enter again to Inspect the registers,The PC tends to remain 0xff80f4. And I disassembly the position,the GUI looks like follow:

     ...

FF80EE    MOV @#60h,T0

FF80F0    AND #65280,T0,T0

FF80F4    BCC 0xff80ee,T0 == #0

FF80F7    MOV dbl(@#60h),AC3

FF80FA    AND #255,mmap(AC3H)

FF80FF    B 0xff84c0

...

 

And I inspect T0 register,It always remains 0. I inspect the data memory word address 0x60,It is 0xff00,never equal ZERO,so strange.

     I can manually change reg T0 to 0xFF00 and run free,but PC never change,PC value can't even be changed manually,

It seems changed,but when I quit CCS after 'run free'  then enter again,the PC remain 0xFF80F4,T0 remain 0xFF00.

Then I quit CCS again,let the HOST continue  to access the DSP HPI without reset the dsp,The HOST can read and write the DSP DARAM correctly.

It seems the DSP is not totally DEAD,only the CPU DOMAIN dead(or crashed!!??).   

(By the way,I probed  the device HDS pin using a oscilloscope,the pin is disasserted,seems it's not the HPI port suspend the DSP core).

 But when the DSP boot success,I connect the emulator and load .out file,and every thing is normal.(I can run the program step by step,the LED toggle On and Off).

TommyG,

I have another hardware question unsure.

I use a outside 20M OSC to drive the 5509A,after reset the DSP use bypass clock mode,and run at 20M by default.

And then I want to load my code to reinitialize  the DPLL,let the DSP run at 200MHz. I use a fix core power supply of 1.6V.

I am not sure if it is a problem.

Because from the 5509A datasheet,I read the Recommended operating condition for CVdd

108M  CVdd=1.2V range 1.14V--1.26V

144M CVdd=1.35V range 1.28V--1.42V

200M CVdd=1.6V range 1.55V-1.65V

I don't know if CVdd=1.6V is correct for a DSP slow  running at 20M.

JianJun,

I don't see anything obviously incorrect with your procedure. 

Just to double check, you are using procedure defined in Boot Loader document SPRA375F? 

The values at 0x60 and 0x61 look correct.  Are you writing to address 0x61 before 0x60?  If not, this could cause some unexpected behavior if upper byte of address 0x60 were non zero and so was the lower byte. 

Have you gone through the debug steps in Sec 3.3 of this document? 

 

TommyG,

   I do writing to address 0x61 before 0x60 absolutely.I have read the SPRA375F document so many times and taken my most attention not to neglect any related information.

   I inspected a new appearance yesterday.Even after  the DSP boot success,run for a while,It  went to crash(running halt) .Of course,the situation is very seldom.

And I suspect the code at 0x4000 is changed by HPI access,connect the emulator to the device then,I inspected it,but it's just in the place,not changed absolutely!!

 in the end,I found the PC point to a unreasonable address,and frozen to the address,can't run again.

   By the way,for saving cost purpose,I adopted two layer PCB for my hardware design,so there is no dedicated GROUND and POWER plane.

 But  I have payed most effort to thicken the power and ground tracks,and use copper pour to improve ground connection.And used bypass capicitors for all power pins.

  Will you think it's a problem? The DSP core is so sensative,and outside tiny interfere will cause it crash? It just run slowly at 20M after all.

  But why the HPI to DARAM communication allways works so well?

 

TommyG,

  I think the bug is located.

  I made a mistake.I use a shared OSC clock of 20M to feed the DSP array of max 16 chips,

  the clock track is too long,even though drived by a LVC245 gate.

      But I have thought it's not problem., because I thought  the frequency of 20M is not too high after all.

 Now,I use a dedicated OSC component  close to drive the single DSP device.All things go right!!

I will test more to verify.

And thanks for your kind and patience to help.

JianJun

Glad to hear you resolved your issue.

Ugh what a hassle. Your solution makes sense though. Have you tried calling software reset instead of branching to the bootloader?
Could you have used the BOOTMODE 0111 for Polling Mode, ultimately polling McSPI?
I dont know which boot pin was high instead of low and I dont know if you had the same issue with other bootmode pins, but I'm guessing you boot from 1101 McSPI 10MHz or 1110 McSPI 40MHz.

Anyway thanks for sharing!

Regards,
Mark

[edit - whoops looks like I was thinking this was the C5517 instead of C5509A, so all of that about the bootmode pins doesnt make any sense at all, sorry]

Hi Mark, I could not find any info on calling a software reset so that is why I branch to bootloader. Could you point me to this info? Also any info on an ESTOP0 instruction like the 2812 family has, would be appreciated as well.