booting on c6713

Thomas,

What are the fail symptoms?  Are you able to connect to the device to see where the program counter is pointing to?

-Tommy

Hello.

Actually I was not aware, that connecting the emulator after the device is powered on is even possible.

I've tested this and found confusing results - I think, I gotta test this more focussed again.

I'll post another follow up, if I've done so.

Thank you for the hint.

regards,

Thomas

The things I've found out:

while flashing: if and only if CE1CTL = 0xFFFFFF13 (should be default for 16-bit boot (HD3=0, HD4=1) anyway), I'm able to read (I've compared the values with the disassembly-window) and write to the flash - the flash performs commands (erase, write (*0x90000555=0xAA; *0x900002AA=0x55; *0x90000555=0xA0; *flashaddr=flashdata), ...) only if they are send in this "format".

I hoped that maybe it works if I treat the whole thing as 8-bit. I guess it does not work with 0xFFFFFF03 or 0xFFFFFF23 due to the shift of the address-bits. Do you think, it's worth testing the whole thing again with "corrected" addresses (to send the correct instructions to the flash)?

while/after booting: I'm only able to connect to the device after booting in 1 of 20 cases, which makes observation pretty annoying. I think, I'm not using the correct procedure to do so - what I'm doing is: power off the board, disconnect JTAG (is this neccesary?), power on the device again, wait, connect JTAG, press [ALT]+[c] in CCS. Any suggestions?

The currently flashed program is some short asm-code, which ends up in an infinite-loop, waiting and switching leds. Do I have to halt the processor somehow to be able to connect?

best regards,

Thomas

Thomas,

Your CCS connect sequence looks reasonable.   Does your test application enable anything like PLL or EMIF?  The emulator should be able to connect to the DSP when it is running, but may be locked out if the DSP is trying to execute corrupt code.

Can you try a test application with just a DSP NOP/IDLE loop followed by a known data pattern?  The IDLE loop (if executed properly) will make it easier for CCS to connect to the device.  Once connected, it will be useful to verify that the code (and known data pattern) is copied correctly from flash to internal memory.

-Tommy

something like:

L_TRAP:

     B L_TRAP

     NOP 7

     .word 0xAAAAAAAA

     .word 0x12345678

     ...

?

I'll try.

Yes, that would be the gist of it.

Sorry for being off a while, but I was pretty busy the last days.

The Op-Code for

B.S2 0x00000000

seems to be 0x00000012

I've tried all combinations (according to endianess: 0x00000012, 0x00001200, 0x00120000, 0x12000000) of that op-code and all bootmodes (8, 16 and 32 bit) - I'm only able to connect to the device if the HD[3:4] dips are set to emu-boot and even for that setting I got to reset the board sometimes to be able to connect (connect - not connected - power down board - reset emu ([CTRL]+[shift]+[r]) - power up board - connect).

All the tests where made with a disabled PLL - the DSP is driven by the external 50 MHz (crystal via CPLD).

On the bus (used for booting) is another FPGA connected, which is not initialized during boot-process (the DSP will program the FPGA) and I'm pretty sure, that this device's pins are tri-state and not interferring the bus at that moment.

Another effect, I'm observing (maybe they are connected to this issue somehow) is that I'm not able to set the devices PLL to run at 300 MHz (processor TMS320C6713BGDP-300) - 200 works - although the core-voltage seems to be stable at 1.4V during switching.

Any suggestions?

Best regards,

Thomas

Litte addon:

After the loop (0x00000012) several nops were also added (0x00000000) to feed the other execution-units.

Since there is test data after the loop (having the LSB alternating) I hoped to be able to see the test-datas LSB (ED0) on an oscilloscope. What I've found differs from power up to power up - in most cases: 0-2 kind of peaks (3.3V - within the first 8 ms), then 8ms at 0.4V, 10ms at 1.9V and after 28ms the line is up (3.3V - stable) - sometimes there are flanks (at the beginning of the phase where the line does not take any levels between 0V and 3.3V) which could be zeros and in very seldom cases the data-line is busy all the time (a lot of zeros and ones) and then I'm even able to connect via the emulator, but after halting the processor is at some invalid address and the memory at 0x0 is not filled with proper data.

But in most of the cases there doesn't seem to be any zero on the line (if the resolution is good enough - with higher resolution its pretty hard to trigger for the event (ED0 "ready") and seeing enough of the boot-sequence) within further 100 ms. (1K at 50 MHz > 20us * wait-cycles of flash)

!!! another thing to mention is, that the uppermost address-bits of the flash are connected to some GPIOs of the processor:

A20   GP14/HD14 (suspicious - HPI is active at startup - is this line 0???)

A21   GP13/HD13 ( - " - )

A22   GP6/EXTINT6

A23   GP7/EXTINT7

Since I'm able to read out the flash, when being connected via the emulator without having those lines initialized in any way, I guess the primary boot loader should also see the same portion of flash, I do. (Maybe I'm wrong with that and I need explicit pull-downs - ending up with four unused GPIOs and 3/4 of the flash wasted isn't pretty, but ok.)

Best regards again,

Thomas

some more:
A20-23 have pull-downs

I was able to do the suggested on the DSK using 8-bit and 16-bit (flash-program was adopted).