These forums are read only, please use our new forums here.

Main :: ToneCore Development Kit

DSP Code Size Limitations?
by clangen on 2009-07-19 02:51:20

This is a follow-up question to the DC(Define Constant) issue:

Is there any limitation for the code size that si bootstrapped to the DSP rather than 1.25kWords p:memory?

If you want to bootstrap a larger application than the TwoBandStereoEQ (this is the application code the ToneCore development kit is shipped with) you have to modify the MCU application according to the TCDDK Users Guide. I did this using the Metrowerks compiler (I had to change the *.map file name in the /bin folder firstly before the IDE could build the project). The linker defines 3843 bytes for DSP code (= 1281 Words) so the maximum program RAM size for the DSP56364 could be bootstrapped in theory.

If you do not change the MCU program it will download 15F words (= 351 in decimal) only, so a part of the application is run on the DSP only, so the bahaviour is unpredictable.

Following the instruction on pages 37 to 42 in the TCDDK Users Guide explains how to change the MCU code. The bootloader mode described on page 36 explains how to flash the MCU.

This is exacly what I did, unfortunately the problem is not solved completely. The bootstrap loader behaves as if only a part of the application is downloaded to the DSP. A good check for this is to send a 'knob' variable to a Debug_Read_from_DSP variable to indicate if the code is alive at this point, like this

        move    x:Knob_1,b1

         move    b1,x:Debug_Read_from_DSP_1   

If you connect the ToneCore pedal to by the USB cable co van see the changing know value. If there is no reaction the corresponding part has not been loaded to the DSP.

The funny thing is after reloading the TwoBandStereoEQ all knobs are 'activated' again. When I uploaded my 1.25kWord application next I can find it in the DSP completely, but it doesn't seem to be bootstrapped by the MCU since after powering up the device it has 'forgotten' half of its features.

Best regards


Re: DSP Code Size Limitations?
by audioartillery on 2009-07-19 08:22:46

Just to make sure I understand you, you're saying the default MCU loader is set up to only download 351 words into P: memory?  That is very surprising.  I haven't looked at the MCU code at all but need to check it out soon.

A better way to prove what you're saying is to DC address = data in most of the program memory, then put a little loop at the bottom that loops over the program memory and outputs the value of each word masked with 0x4E0.

Re: DSP Code Size Limitations?
by clangen on 2009-07-19 11:33:43

Inserted below you see the DSPCode.c code snippet of the MCU Example Code shipped with the ToneCore DSP Development Kit.


#include "typedef.h"

     This is the code that will be downloaded to the DSP.
     You can modify this constant based on the dumped file displayed by the GUI.
     Make sure you change the code size (first 3 bytes in the array)

const UINT8 DSP_Code[] @ 0xC000 =
     0x00,   0x01,   0x60,     /* This is the size of the code in words*/
     0x00,   0x00,   0x00,     /* This is the starting add


I guess the MCU is preloaded with that example. $160 corresponds to 352 decimal. Makes absolutely sense to me since the TwoBandStereoEQ example that comes preloaded to the MCU is exactly $160 words.

I modified the code snippet to $4FF or $500 and inserted my application (in words), but it did nor work properly after powering up.

Anyway I can download the code using the ToneCore DSP Development kit and run it - the strange behaviour is in the stand alone mode only. This gives me a hint that the code size is limted by a reason unknown to me.

The linker code segment for the DSPCode object file is $426 bytes corresponding to 1062 bytes decimal (this is 354 words). Subtracting the six header bytes to this yields 1056 bytes, divide this result by three - this is 352.

.abs_section_c000               1062     R     0xC000     0xC425   .absSeg153

After modifying the DSPCode.c file the linker code segment size for the DSPCode object file is $F03 bytes = 3843 bytes decimal corresponding to 1281 words (1279 code words plus two 'header' words).

.abs_section_c000               3843     R     0xC000     0xCF02   .absSeg153

This is all correct but the behaviour is strange - I cannot explain this:

After downloading the TwoBandStereoEQ I can receive all Debug read from DSP variables.When I download my application all works fine (all knob movements are returning variables). After the next powering up some code seems to be 'lost'.



Re: DSP Code Size Limitations?
by Angelo on 2009-07-31 14:44:50

I saw your post and tried it out by increasing the size of my code to the full 1280 program words.

I am having no issues loading DSP code that takes advantage of all of the available p:mem on

the 56364.   I can load a .cld file that has the program memory of the DSP completely filled (0x4FF)

and I have no issues with my running my effect. 

Re: DSP Code Size Limitations?
by clangen on 2010-01-09 04:32:47

Hi Angelo,

after retrying to get a $500 sized DSP code run, I can report the following:

- After powering up the device (waitng for 20 seconds) the sknob parameters are 'lost' and do not give Debug Read from DSP feedback as well as they do not give control over the parameters anymore.

- I can load the 'TwoBandStereoEQ' project (which is smaller) and have feedback from the knobs again.

- when I load my own application (a compressor/limiter that is filled p with 'nop' instructions to achieve exactly $500 size) either by bootstrapping the MCU or by downloading it to the I can run this as long as the power supply remains connected.

- I have modified the MCU code file 'DSPcode.c' for $500 code size and recompiled the whole thing using CodeWarrior:

const UINT8 DSP_Code[] @ 0xC000 =
    0x00,   0x05,   0x00,     /* This is the size of the code in words -- This is expanded to $500 24bit words*/ 
    0x00,   0x00,   0x00,     /* This is the starting address of RAM where the code will be stored */

Attached you can find the DSP object code. Here is a short description what the knobs are adjusting.

; Knobs
; *1st knob sets the compressor threshold
; *2nd knob sets the compressor release time
; *3rd knob sets the compressor attack time
; *4th knob sets the compressor ratio
; *5th knob sets the compressor side chain filter
; *6th knob sets the compressor post gain

I cannot find a reason for the strange behaviour I observe. By the way the 'Flanger' project you can find on, see:


'loses'the knob feedback to the ToneCore gui as well but remains having access on the DSP parameters.

Any idea for the strange beaviour?

Best regards


Re: DSP Code Size Limitations?
by line6lm on 2010-02-04 11:21:47


It's been a bit since we've heard from you. We're going to assume your question has been answered and close this thread. If you still have questions please feel free to re-open this thread and a rep will respond accordingly. Thanks!

Re: DSP Code Size Limitations?
by clangen on 2010-02-04 11:51:24

Hi line6lm,

I'm sorry but the problem hasn't been solved yet even if I didn't repost my question again. The described loss of control after a 'cold start' is still an open issue. I cannot explain why this can happen to a program that can be controlled properly after flashing it to the MCU.

This phenomenon can be observed for large sized programs only. Please have a try using the attached object code example to my last email in this thread.

I even tried to fix the problem by recompiling the MCU code and looking to the object start addresses carefully - anyway I've no idea for a solution.

Best regards


Re: DSP Code Size Limitations?
by groxter on 2010-02-04 14:02:52

I can corroborate Angelo's assertion that a $500 word program works fine.

Two things come to mind when reading and thinking about your approach:

1) If at any point in your DSP assembly code you skip even a single memory location, not having it filled with code or data, the tools will stop there and not load your whole program.

Look at the assembler output listing, any addresses with no contents listed will do this.

2) I would recommend approaching the device slowly and carefully, building up your program, testing and confirming functionality as you grow it.  I have been programming a long time,

on all kinds of devices and platforms, and often I see coders who write a long program and then try to debug it.  If you start with just the example startup code provided, and a null ISR doing nothing, then proceed to develop your code slowly and carefully, testing as you go, you can't go wrong, and won't end up with a large mess where the smallest unnoticed detail can break it. Forgive me for being pedantic, for any coders reading this to whom it is obvious, but the tendency to not test-as-you-write is way too common in inexperienced programmers, from my observations.

You don't need good luck, you need good methodology.

Re: DSP Code Size Limitations?
by clangen on 2010-02-07 01:45:03

Hi groxter,

thank you for the advice how to do software engineering, You're absolutely right. Here my comments:

1.) Yes, I took a look to the listing file, there are no skipped memory locations. If so I guess the program couldn't be booted by the DSP at all even at 'warm start'. Anyway, I'm not sure about this since I don't know the difference for the MCU code if the DSP program is flashed and started instantly or powered up later.

2.) I did exactly what you recommend. The program was divided in parts and tested individually. Before it was ported to the ToneCore pedal it was developed on a dedicated hardware platform and debugged using the OnCE interface.

Unfortunately the ToneCore pedal doesn't support the use of the regular tools (debugger, OnCE interface) directly. Since that you can only use the 'burn and crash' approach. Even this port was done piecewise until I could observe the said phenomenon. I experimented a lot with the code to find the problem I tried to describe as detailled as even possible.

Let me extend your comment to 'you don't need good luck, you need good methodology' with 'and the appropiate tools'.

Back to my office in the mid of the next week I will add the OnCE interface to the pedal to upload the *.cld file to the PC and disassemble it. Then I can see what's going on here and have a chance to fix it.This is just the six pin connector you can see on p.8 in the TCDDK Hardware Guide document that was not populated for the shipped products. I was hoping that those guys who did the MCU programming could find an explanation.

Anyway I will report how to interface the pedal to the debug interface and the results I fould for the observed behaviour. I never give up. Please understand that general advices won't help to solve problems. Only a clear description of what's wrong does.

Best regards


Re: DSP Code Size Limitations?
by groxter on 2010-02-07 02:40:01

Hi Christian,

Sounds like you have a plan.  No offense intended on the engineering advice, nor was it intended to solve your problem.  I'm uncertain how much anyone here can help you, though, without having access to every file of your project (no I'm not asking for them) because, and excuse the general advice, when there is a contradiction, at least one of your assumptions must be false.  Since $500 word programs do run fine, then there logically must be a false assumption involved, when the conclusion is that the size of the program alone is causing it to fail (one possible assumption is that the hardware is not malfunctioning.)

Good luck, I'll be interested in hearing what you determine is happening.

Re: DSP Code Size Limitations?
by Angelo on 2010-02-08 17:00:08

Hi Christian,

I looked at the flanger code that you provided the link for.

The reason that it 'loses' some feedback in the GUI is because

the GUI is only capable of reading from 4 memory location for display.

If you don't write any data into these registers, then the GUI will be unable to

display anything other than how they were initialized.

These locations are:

Debug_Read_from_DSP_1   // 16h send data to the ToneCoreGUI application

Debug_Read_from_DSP_2   // 17h send data to the ToneCoreGUI application

Debug_Read_from_DSP_3   // 18h send data to the ToneCoreGUI application

Debug_Read_from_DSP_4   // 19h send data to the ToneCoreGUI application

I don't know what is going on in your code, but if your code is 1280 words and

under then it will run just fine.   You are either not writing into these debug registers,

or the code that should is not being called.


Re: DSP Code Size Limitations?
by clangen on 2010-03-05 05:13:13

I've taken a closer look to the memory expansion for the DSP56364 done by the ToneCore Module for the ToneCore Programmer Dock. The DSP is configured to boot in Mode $D from SHI in slave SPI mode. Thus the MCU uploads the code to the DSP by running the DSP.c code (you find this code in the ..TCDDK v1.0\MCU sample code\Sources folder).

The configuration for the extended mode is done by the following assembly code instructions

    bset    $7,omr
    jmp    $ff0000

This is the code snipped that is downloaded firstly during the boot process (see DSP.c):

/* This is the compiled code for the DSP that expands the DSP program memory to 1.25k */
const UINT8 gu8CodeToExpandDSP_RAM[] = {0x0A ,0xFA, 0x67,    
                                        0x0A, 0xF0, 0x80,
                                        0xFF, 0x00, 0x00};

Surely the first line adjusts the memory to Mode 1 by setting the MS bit. The next instruction sets the program to the address $ff0000 where the bootloader starts and loads the entire code to the p:memory. Anyway this is done automatically since the MODD pin is pulled high. Flipping the MODA pin doesn't have any impact on this.

The bad news is that the first line that adjusts the extended memory is never run. I've checked this by adding a OnCE interface to the ToneCore Programmer Dock as described in the tread 'Using Symphony Studio to debug on-target?'. Using the Suite56 debugger (I prefer this) I could see that the MS bit ($7 in the omr register) wasn't set after booting the DSP. Setting this bit and resetting the DSP by the debugger the entire code was loaded to the DSP memory since the address space between p:$200 and p:$4FF is walid.

I tried to fix the problem by applying a second reset to the DSP by the MCU, but this didn't help, but it helps to explain the behaviour described in this tread prevously. After resetting the DSP several times the two instruction may be resident in the p:memory and exected before the next reboot in the now extended memory mode.

This gives the explanation as well why the extended mode works after bootstrapping the DSP by the ToneCore DSP Developer Kit what I called 'warm start'. The two instructions are executed in this case since the DSP is reset to address $0 and jumps to the bootloader next in extended memory mode.

To solve this issue the MCU bootloader program should be rewritten using the so called 'overlay technique'. I've done this for the DSP56364 some years before to load the p:, x: and y: memories in expanded mode: Firstly a small program has to be uploaded to the DSP and run. This program adjusts the proper memory mode replaces the original bootloader to download all program and data segments.

Using Mode $D (slave SPI) the MCU has to do a waitstate to make sure that the downloaded code is running to wait for the following upload. Since the small code fragment that was uploaded to the DSP firstly is overwritten, this technique is called 'overlay'

Yes, it's possible to extend the DSP memory to 1.25kWord, but this has to be done by the MCU program properly. I do not volunteer to do this work since the ToneCore DSP Developer Kit is neither my product nor project ;-). For now, I'm happy to have analyzed the problem and can explain the behaviour.

Best regards


Re: DSP Code Size Limitations?
by Angelo on 2010-03-05 11:29:30


You are wrong. 

The command to extend the memory is executed.

This is very easy to prove.

I've added NOPs to the provided example code

to increase the pmem size to the full 1.25K

and it works just fine.

I've included the files to prove it.

Your code is not working because you have a bug in

it, not because the pmem is not being expanded.


The information above may not be current, and you should direct questions to the current forum or review the manual.