Reply by Michael Dunn October 31, 20072007-10-31
Hello Simon,

Any luck with your GaoTek emulator??

,mikedunn
On 10/25/07, Simon E. Mushi wrote:
>
> Hi,
>
> I am using a GaoTek USB XDS510 with CCS 3.3 to do development on an
> Innovative Integration C6713 based board.
>
> After following setup instructions in the manual I get the following
> error in CCS starting up
> "Fatal Error during : OCS
> SC_ERR_OCS_PORT <-118>"
>
> What does this mean?
>
> I have run xdsprobe -f gao.cfg -p -x240 -r -v and the emulator claims
> to reset successfully.
>
> I have also run xdsprobe -f gao.cfg -p 0x240 -y and tbc functionality is
> verified successfully.
>
> I get many errors when verifying the scan path integrity using the -i
> switch.
>
> I have independently confirmed that the C6713 baseboard works correctly,
> I just cannot get it to talk to the debugger!
>
> Any advice is welcome,
>
> Respectfully,
> Simon Mushi
>

--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
Reply by "Simon E. Mushi" October 28, 20072007-10-28
Hi Mike,

I get the following error on running CCS

Error connecting to the target:
Error 0x00000202/-1024
Error during: Memory, OCS,
PTI_ERR_PREV_IROP_CMD Error Occured at 0x01840000
I/O Port = 240

Board Name: mine
Cpu Name: TMS320C6710_0
xdsprobe -g -c give i still mixed up on word boundaries
-----[Perform the Given Data scan-test on the JTAG
IR]-----------------------

This test will use blocks of 512 32-bit words.
This test will be applied forever.
It uses all of the 10 different test-cases.

Do a test using 0x5533CCAA.
Test 1 Word 0: scanned out 0x5533CCAA and scanned in 0xF32A8240.
Test 1 Word 1: scanned out 0x5533CCAA and scanned in 0xF32A954C.
Test 1 Word 2: scanned out 0x5533CCAA and scanned in 0xF32A954C.
Test 1 Word 3: scanned out 0x5533CCAA and scanned in 0xF32A954C.
Test 1 Word 4: scanned out 0x5533CCAA and scanned in 0xF32A954C.
Test 1 Word 5: scanned out 0x5533CCAA and scanned in 0xF32A954C.
Test 1 Word 6: scanned out 0x5533CCAA and scanned in 0xF32A954C.
Test 1 Word 7: scanned out 0x5533CCAA and scanned in 0xF32A954C.
The details of the first eight errors have been provided.
The utility will now report only the count of failed tests.
Scan tests: 58, skipped: 22, failed: 36
Some of the values were corrupted - 99.8 percent.

The JTAG IR Given Data scan-test has failed.

-----[Perform the Given Data scan-test on the JTAG
DR]-----------------------

This test will use blocks of 512 32-bit words.
This test will be applied forever.
It uses all of the 10 different test-cases.

Do a test using 0x5533CCAA.
Test 1 Word 0: scanned out 0x5533CCAA and scanned in 0xAA679954.
Test 1 Word 1: scanned out 0x5533CCAA and scanned in 0xAA679954.
Test 1 Word 2: scanned out 0x5533CCAA and scanned in 0xAA679954.
Test 1 Word 3: scanned out 0x5533CCAA and scanned in 0xAA679954.
Test 1 Word 4: scanned out 0x5533CCAA and scanned in 0xAA679954.
Test 1 Word 5: scanned out 0x5533CCAA and scanned in 0xAA679954.
Test 1 Word 6: scanned out 0x5533CCAA and scanned in 0xAA679954.
Test 1 Word 7: scanned out 0x5533CCAA and scanned in 0xAA679954.
The details of the first eight errors have been provided.
The utility will now report only the count of failed tests.
Scan tests: 102, skipped: 40, failed: 62
Some of the values were corrupted - 99.8 percent.

The JTAG DR Given Data scan-test has failed.
--Simon
On Fri, 2007-10-26 at 19:21 -0500, Michael Dunn wrote:
> Simon,
>
> I have attached a couple of files that might [or might not] work
> around your problem.
> You will need to remove the '.txt' extensions.
> gao2.cfg is a substitute for gao.cfg when you run xdsprobe [you will
> not need to specify the address, it is embedded in the file].
> gaotek_hack.xml essentially contains the same info for CCS setup. It
> should be copied into the
> 'C:\CCStudio_v3.3\drivers\TargetDB\connections' directory.
> When you bring up CCS setup, delete any existing configurations, and
> select the 'create board' tab near the bottom.
> Drag the gaotek configuration into the left pane - you will have to
> enter a name for it [any name will do].
> You should now see some 'processors in the center pane - drag over the
> c6710 and save. You don't need to do any 'extra config file stuff'.
> If I didn't make any stupid typos, CCS should try to come up.
> I suspect that there is some sort of 'overrun condition' occuring in
> the gao.dll. The extra settings that I put in the files are an
> attempt to 'slow down' the emulation driver and USCIF. The only side
> effects would be a possible reduction in performance - obviously not a
> priority at the moment.
>
> Let me know how things go with your immediate problem and gaotek as well.
>
> mikedunn
> >
--
Simon E. Mushi
www.people.virginia.edu/~sem5t/
Reply by Michael Dunn October 28, 20072007-10-28
<?xml version="1.0"?>






















Reply by Michael Dunn October 26, 20072007-10-26
Hello Simon,

On 10/26/07, Simon E. Mushi wrote:
> Hi Mike,
>
> Actually my DSP baseboard (Innovative M6713) is not a DSK and is PCI
> based and does not have a built-in emulator/debugger, that's why I am
> using the XDS510 to connect to it's JTAG port.

I apologize - I got you mixed up with a different GAO problem.
>
> > 3. Use a scope and probe the JTAG connector pins 3 [TDI] and pin 7
> > [TDO]. You should see similar activity on both pins. Technically,
> > TDO is the same as TDI delayed by 46 clocks.
> I disconnected the pod from the baseboard and probed these pins on the
> baseboard connector and TDI and TDO don't have any activity (3.3V
> fixed)...but the DSP isn't running anything so isn't this normal?
>
> > 4. Take a look at pin 9 [TCLK]. This is the JTAG clock and it needs
> > to have clean edges.
> I don't see a signal on TCLK aswell. TCLK is provided by the JTAG pod,
> but once I disconnect it from the baseboard, isn't it supposed to stop
> outputting a clk?
>
> Maybe I was thinking about this probing incorrectly, did you want me to
> tap into the jtag cable while it is connected to the target?

more apologies - I know what I meant, I just didn't say it clearly.
The 'do as I say' procedure is to remove the cable, attach 2 probes
close to the board using the normal probe hook. Then reattach the
cable and run your test. This will keep you from blowing anything
out. I have a 14 pin wire wrap connector that I put on the board's 14
pin connector and then attach the emulator cable to the wirewrap pins.
They are nice and long - a careful person can attach and remove
probes without removing any cables.

>
> > 2. Use 'xdsprobe -g -c' [this will send a continuous 32 bit pattern]
>
> Also, this is the full result of the xdsprobe -g -c test
>
> -----[Perform the standard path-length test on the JTAG IR and
> DR]-----------
>
> This path-length test uses blocks of 512 32-bit words.
>
> The test for the JTAG IR instruction path-length failed.
> The many-ones then many-zeros tested length was -13713 bits.
> The many-zeros then many-ones tested length was 32 bits.
>
> The test for the JTAG DR bypass path-length failed.
> The many-ones then many-zeros tested length was 33 bits.
> The many-zeros then many-ones tested length was -16400 bits.
>
> -----[Perform the Given Data scan-test on the JTAG
> IR]-----------------------
>
> This test will use blocks of 512 32-bit words.
> This test will be applied forever.
> It uses all of the 10 different test-cases.
>
> Do a test using 0x5533CCAA.
> Test 1 Word 0: scanned out 0x5533CCAA and scanned in 0xF32A8240.
> Test 1 Word 1: scanned out 0x5533CCAA and scanned in 0xF32A954C.
> Test 1 Word 2: scanned out 0x5533CCAA and scanned in 0xF32A954C.
> Test 1 Word 3: scanned out 0x5533CCAA and scanned in 0xF32A954C.
> Test 1 Word 4: scanned out 0x5533CCAA and scanned in 0xF32A954C.
> Test 1 Word 5: scanned out 0x5533CCAA and scanned in 0xF32A954C.
> Test 1 Word 6: scanned out 0x5533CCAA and scanned in 0xF32A954C.
> Test 1 Word 7: scanned out 0x5533CCAA and scanned in 0xF32A954C.
> The details of the first eight errors have been provided.
> The utility will now report only the count of failed tests.
> Scan tests: 83, skipped: 32, failed: 51
> Some of the values were corrupted - 99.8 percent.

An analysis of the data pattern indicates that you are probably
getting the correct bits!!
0x5533CCAA followed by 0x5533CCAA 0101.0101.0011.0011.1100.1100.1010..0101.0101.0011.0011.1100.1100.1010
Now find the 4 consecutive 1's and cal them F. I will try to illustrate:
xxxx.xxxx.xxxx.xx11.1100.1100.1010..0101.0101.0011.0011.1100.1100.1010
Same pattern as above. We will ignore the x's and "resync our nibbles::
11.11-00.11-00.10-10..01-01.01-01.00-11.00-11.11-00.11-00.10-xx
Which gives us:
F-3-2-9-5-4-C--F-3...
This also looks familar. I believe that the skill and efficiency with
which this was done could only be accomplished with software :-).
i.e. gao.dll [sp??] is broken.

>
> The JTAG IR Given Data scan-test has failed.
>
> -----[Perform the Given Data scan-test on the JTAG
> DR]-----------------------
>
> This test will use blocks of 512 32-bit words.
> This test will be applied forever.
> It uses all of the 10 different test-cases.
>
> Do a test using 0x5533CCAA.
> Test 1 Word 0: scanned out 0x5533CCAA and scanned in 0xAA679954.
> Test 1 Word 1: scanned out 0x5533CCAA and scanned in 0xAA679954.
> Test 1 Word 2: scanned out 0x5533CCAA and scanned in 0xAA679954.
> Test 1 Word 3: scanned out 0x5533CCAA and scanned in 0xAA679954.
> Test 1 Word 4: scanned out 0x5533CCAA and scanned in 0xAA679954.
> Test 1 Word 5: scanned out 0x5533CCAA and scanned in 0xAA679954.
> Test 1 Word 6: scanned out 0x5533CCAA and scanned in 0xAA679954.
> Test 1 Word 7: scanned out 0x5533CCAA and scanned in 0xAA679954.
> The details of the first eight errors have been provided.
> The utility will now report only the count of failed tests.
> Scan tests: 137, skipped: 54, failed: 83
> Some of the values were corrupted - 99.8 percent.
>
> The JTAG DR Given Data scan-test has failed.
> I am currently exchanging email with an engineer from GaoTek, and he's
> sent me two different drivers which have both failed, seems like trial
> and error approach...

Have you asked the GaoTek person if they have successfully run this
test with their emulator and a 6713?? [I know that they make a 6713
board to test with]

I will post additional info shortly.

mikedunn

>I feel I am running blind because the USCIF error
> codes are only partially defined in the documentation...hopefully we'll
> get somewhere this weekend is going to be a bummer!
>
> Thanks for your continued assistance!
>
> Best,
>
> Simon
Reply by "Simon E. Mushi" October 26, 20072007-10-26
Hi Mike,

Actually my DSP baseboard (Innovative M6713) is not a DSK and is PCI
based and does not have a built-in emulator/debugger, that's why I am
using the XDS510 to connect to it's JTAG port.

> 3. Use a scope and probe the JTAG connector pins 3 [TDI] and pin 7
> [TDO]. You should see similar activity on both pins. Technically,
> TDO is the same as TDI delayed by 46 clocks.
I disconnected the pod from the baseboard and probed these pins on the
baseboard connector and TDI and TDO don't have any activity (3.3V
fixed)...but the DSP isn't running anything so isn't this normal?

> 4. Take a look at pin 9 [TCLK]. This is the JTAG clock and it needs
> to have clean edges.
I don't see a signal on TCLK aswell. TCLK is provided by the JTAG pod,
but once I disconnect it from the baseboard, isn't it supposed to stop
outputting a clk?

Maybe I was thinking about this probing incorrectly, did you want me to
tap into the jtag cable while it is connected to the target?

> 2. Use 'xdsprobe -g -c' [this will send a continuous 32 bit pattern]

Also, this is the full result of the xdsprobe -g -c test

-----[Perform the standard path-length test on the JTAG IR and
DR]-----------

This path-length test uses blocks of 512 32-bit words.

The test for the JTAG IR instruction path-length failed.
The many-ones then many-zeros tested length was -13713 bits.
The many-zeros then many-ones tested length was 32 bits.

The test for the JTAG DR bypass path-length failed.
The many-ones then many-zeros tested length was 33 bits.
The many-zeros then many-ones tested length was -16400 bits.

-----[Perform the Given Data scan-test on the JTAG
IR]-----------------------

This test will use blocks of 512 32-bit words.
This test will be applied forever.
It uses all of the 10 different test-cases.

Do a test using 0x5533CCAA.
Test 1 Word 0: scanned out 0x5533CCAA and scanned in 0xF32A8240.
Test 1 Word 1: scanned out 0x5533CCAA and scanned in 0xF32A954C.
Test 1 Word 2: scanned out 0x5533CCAA and scanned in 0xF32A954C.
Test 1 Word 3: scanned out 0x5533CCAA and scanned in 0xF32A954C.
Test 1 Word 4: scanned out 0x5533CCAA and scanned in 0xF32A954C.
Test 1 Word 5: scanned out 0x5533CCAA and scanned in 0xF32A954C.
Test 1 Word 6: scanned out 0x5533CCAA and scanned in 0xF32A954C.
Test 1 Word 7: scanned out 0x5533CCAA and scanned in 0xF32A954C.
The details of the first eight errors have been provided.
The utility will now report only the count of failed tests.
Scan tests: 83, skipped: 32, failed: 51
Some of the values were corrupted - 99.8 percent.

The JTAG IR Given Data scan-test has failed.

-----[Perform the Given Data scan-test on the JTAG
DR]-----------------------

This test will use blocks of 512 32-bit words.
This test will be applied forever.
It uses all of the 10 different test-cases.

Do a test using 0x5533CCAA.
Test 1 Word 0: scanned out 0x5533CCAA and scanned in 0xAA679954.
Test 1 Word 1: scanned out 0x5533CCAA and scanned in 0xAA679954.
Test 1 Word 2: scanned out 0x5533CCAA and scanned in 0xAA679954.
Test 1 Word 3: scanned out 0x5533CCAA and scanned in 0xAA679954.
Test 1 Word 4: scanned out 0x5533CCAA and scanned in 0xAA679954.
Test 1 Word 5: scanned out 0x5533CCAA and scanned in 0xAA679954.
Test 1 Word 6: scanned out 0x5533CCAA and scanned in 0xAA679954.
Test 1 Word 7: scanned out 0x5533CCAA and scanned in 0xAA679954.
The details of the first eight errors have been provided.
The utility will now report only the count of failed tests.
Scan tests: 137, skipped: 54, failed: 83
Some of the values were corrupted - 99.8 percent.

The JTAG DR Given Data scan-test has failed.
I am currently exchanging email with an engineer from GaoTek, and he's
sent me two different drivers which have both failed, seems like trial
and error approach...I feel I am running blind because the USCIF error
codes are only partially defined in the documentation...hopefully we'll
get somewhere this weekend is going to be a bummer!

Thanks for your continued assistance!

Best,

Simon
Reply by Michael Dunn October 26, 20072007-10-26
Simon,

On 10/26/07, Simon E. Mushi wrote:
> Hi Michael,
>
> Thanks for the reply and tips! I made some changes to the xds510.xml
> driver file template

GAO Tek should have provided an xml file with a different name
[probably with 'GAO' in it. It is no big deal unless they have added
additional settings.

> and am now getting the error
> "Error during: Memory:OCS
> PTI_ERR_PREV_IROP_CMD Error occured at 0x01BC0028
>
> I/O PORT 240
> Board Name: mine
> Cpu Name: TMS320C671x_0
>
> Abort: Close Code Composer Studio.
> Retry: Try to connect to the target again.
> Cancel: Remain disconnected from the target
> Diagnostic: Run diagnostic utility.
> "

This is some type of internal error from the c6x emulation driver that
occurred. The 0x01BCxxxx memory space has to do with accessing
internal debug logic. Did you get this error during connect or did
you get past connect?? If you were try to perform a debug function,
what was it??
>
> Answering your questions:
>
> 1. The contents of gao.cfg are:
> ;CFG-2.0
> [POD_DRVR] 'GAO.dll'
>
> 2. My output of the xdsprobe -F gao.dll -p0x240-g -c is
> -----[Print the controller-open software
> log-file]---------------------------
>
> This utility has selected an XDS510 class product.
> This utility will load the adapter 'GAO.dll'.
> This utility will operate on port address '0x0240'.
> TDS510USB Emulator found (USB 2.0 port)
> The controller does not use a programmable FPGA.
> The emulator adapter is named 'GAO.dll'.
> The emulator adapter is titled 'Custom block-mode adapter for use with
> an TDS51
> '.
> The emulator adapter is version '33.0.0.0'.
> The emulator adapter is using 'Block-Mode'.
> The controller has a version number of '1' (0x0001).
> The controller has an insertion length of '16' (0x0010).
> The local memory has a base address of '0' (0x000000).
> The local memory has a word capacity of '262144' (0x040000).
>
> -----[Perform the standard path-length test on the JTAG IR and
> DR]-----------
>
> This path-length test uses blocks of 512 32-bit words.
>

The info looks ok to this point.

> The test for the JTAG IR instruction path-length failed.
> The many-ones then many-zeros tested length was -13712 bits.
> The many-zeros then many-ones tested length was 46 bits.

This is a bit strange. The first test [-13712] must have failed so
badly that the result of the math to compute the scan path length came
up with a bogus answer.
46 bits is the correct IR length.
>
> The test for the JTAG DR bypass path-length succeeded.
> The JTAG DR bypass path-length is 1 bits.

This indicates that the same tests worked on the DR [it should be 1]
>
> -----[Perform the Given Data scan-test on the JTAG
> IR]-----------------------
>
> This test will use blocks of 512 32-bit words.
> This test will be applied forever.
> It uses all of the 10 different test-cases.
>
> Do a test using 0x5533CCAA.
> Test 1 Word 0: scanned out 0x5533CCAA and scanned in 0xF32A8040.
> Test 1 Word 1: scanned out 0x5533CCAA and scanned in 0xF32A954C.
> Test 1 Word 2: scanned out 0x5533CCAA and scanned in 0xF32A954C.
> Test 1 Word 3: scanned out 0x5533CCAA and scanned in 0xF32A954C.
> Test 1 Word 4: scanned out 0x5533CCAA and scanned in 0xF32A954C.
> Test 1 Word 5: scanned out 0x5533CCAA and scanned in 0xF32A954C.
> Test 1 Word 6: scanned out 0x5533CCAA and scanned in 0xF32A954C.
> Test 1 Word 7: scanned out 0x5533CCAA and scanned in 0xF32A954C.
> The details of the first eight errors have been provided.
> The utility will now report only the count of failed tests.
> Scan tests: 1267, skipped: 506, failed: 761

After running this test, what happened when you hit the space bar and
it started testing the DR?? Did it fail similarly or pass??

I have never seen a GAO Tek emulator. Just to be sure that we are not
being deceived, run these same tests on your DSK to make sure that
they will run correctly on the GAO hw/sw.
>
> > 3. Use a scope and probe the JTAG connector pins 3 [TDI] and pin 7
> > [TDO]. You should see similar activity on both pins. Technically,
> > TDO is the same as TDI delayed by 46 clocks.
> > 4. Take a look at pin 9 [TCLK]. This is the JTAG clock and it needs
> > to have clean edges.
> I don't have a pair of good probes in this lab right now...should get a
> hold of some tomorrow.
>
> > 5. Also, what is the TCLK rate of the GAO emulator??
> TCLK is 10.368MHz as a default in CCSetup
That is the TCLK rate of a TI XDS510 emulator. If you were using the
xds510.xml file, that is where CCS setup was getting the number. I
was curious about what the GAO Tek documentation said [or the observed
frequency of TCLK on a scope].

My current thoughts:
If you get the same or similar errors on your working DSK, the
xdsprobe errors are related to a GAO Tek hw/sw problem and we should
focus on the CCS error.

If the tests run cleanly on your DSK, then there may be a signal
quality problem relating to TDI/TDO/TCLK.

Just out of curiousity, did all of the tests with the -i option fail??

mikedunn

>
> Cheers,
>
> Simon
Reply by "Simon E. Mushi" October 26, 20072007-10-26
Hi Michael,

Thanks for the reply and tips! I made some changes to the xds510.xml
driver file template and am now getting the error
"Error during: Memory:OCS
PTI_ERR_PREV_IROP_CMD Error occured at 0x01BC0028

I/O PORT 240
Board Name: mine
Cpu Name: TMS320C671x_0

Abort: Close Code Composer Studio.
Retry: Try to connect to the target again.
Cancel: Remain disconnected from the target
Diagnostic: Run diagnostic utility.
"

Answering your questions:

1. The contents of gao.cfg are:
;CFG-2.0
[POD_DRVR] 'GAO.dll'

2. My output of the xdsprobe -F gao.dll -p0x240-g -c is
-----[Print the controller-open software
log-file]---------------------------

This utility has selected an XDS510 class product.
This utility will load the adapter 'GAO.dll'.
This utility will operate on port address '0x0240'.
TDS510USB Emulator found (USB 2.0 port)
The controller does not use a programmable FPGA.
The emulator adapter is named 'GAO.dll'.
The emulator adapter is titled 'Custom block-mode adapter for use with
an TDS51
'.
The emulator adapter is version '33.0.0.0'.
The emulator adapter is using 'Block-Mode'.
The controller has a version number of '1' (0x0001).
The controller has an insertion length of '16' (0x0010).
The local memory has a base address of '0' (0x000000).
The local memory has a word capacity of '262144' (0x040000).

-----[Perform the standard path-length test on the JTAG IR and
DR]-----------

This path-length test uses blocks of 512 32-bit words.

The test for the JTAG IR instruction path-length failed.
The many-ones then many-zeros tested length was -13712 bits.
The many-zeros then many-ones tested length was 46 bits.

The test for the JTAG DR bypass path-length succeeded.
The JTAG DR bypass path-length is 1 bits.

-----[Perform the Given Data scan-test on the JTAG
IR]-----------------------

This test will use blocks of 512 32-bit words.
This test will be applied forever.
It uses all of the 10 different test-cases.

Do a test using 0x5533CCAA.
Test 1 Word 0: scanned out 0x5533CCAA and scanned in 0xF32A8040.
Test 1 Word 1: scanned out 0x5533CCAA and scanned in 0xF32A954C.
Test 1 Word 2: scanned out 0x5533CCAA and scanned in 0xF32A954C.
Test 1 Word 3: scanned out 0x5533CCAA and scanned in 0xF32A954C.
Test 1 Word 4: scanned out 0x5533CCAA and scanned in 0xF32A954C.
Test 1 Word 5: scanned out 0x5533CCAA and scanned in 0xF32A954C.
Test 1 Word 6: scanned out 0x5533CCAA and scanned in 0xF32A954C.
Test 1 Word 7: scanned out 0x5533CCAA and scanned in 0xF32A954C.
The details of the first eight errors have been provided.
The utility will now report only the count of failed tests.
Scan tests: 1267, skipped: 506, failed: 761
> 3. Use a scope and probe the JTAG connector pins 3 [TDI] and pin 7
> [TDO]. You should see similar activity on both pins. Technically,
> TDO is the same as TDI delayed by 46 clocks.
> 4. Take a look at pin 9 [TCLK]. This is the JTAG clock and it needs
> to have clean edges.
I don't have a pair of good probes in this lab right now...should get a
hold of some tomorrow.

> 5. Also, what is the TCLK rate of the GAO emulator??
TCLK is 10.368MHz as a default in CCSetup
Cheers,

Simon
Reply by "Simon E. Mushi" October 25, 20072007-10-25
Hi,

I am using a GaoTek USB XDS510 with CCS 3.3 to do development on an
Innovative Integration C6713 based board.

After following setup instructions in the manual I get the following
error in CCS starting up
"Fatal Error during : OCS
SC_ERR_OCS_PORT <-118>"

What does this mean?

I have run xdsprobe -f gao.cfg -p -x240 -r -v and the emulator claims
to reset successfully.

I have also run xdsprobe -f gao.cfg -p 0x240 -y and tbc functionality is
verified successfully.

I get many errors when verifying the scan path integrity using the -i
switch.

I have independently confirmed that the C6713 baseboard works correctly,
I just cannot get it to talk to the debugger!

Any advice is welcome,

Respectfully,
Simon Mushi