Dragomir-

> Thank you for the advices! With your help I have identified the
> piece of code that is causing the problem. I am still not sure if it is
> a hardware or software problem, but it is provoked by the software. I
> have found the piece of code by inserting endless loops in the software
> and then observing the result.

That's good work. Debug may not be as fun as design, but certainly it's just as
challenging!

> The flash got corrupted after this line:
> if (Proto_CPLD_Input_SW1==1)
> Unfortunately I can not understand why this comparison erases
> the flash.

As Richard mentions, it's probably not just one line of code that's causing a bad
effect. You might have found a loose string, then you have to pull on it to unravel
all that's going on. There might be a combination of things that eventually cause
the Flash to become corrupted.

You should put a logic analyzer on the Flash strobe/control signals and try to "see"
exactly what the Flash sees. Obviously if it never gets a true, accurate write
sequence then it must be something else that is causing it to lose data. But if it
does, then you would know that your DSP code and/or onboard firmware is somehow
emitting that sequence.

> The CCS is not showing me any code, after this command
> line, when I switch on “view mixed source/asm”.
> The integer variable Proto_CPLD_Input_SW1 initializes its
> value by the following commands:
> io_port_values=*(unsigned volatile int *)IO_PORT;
> Proto_CPLD_Input_SW1=(io_port_values&0x0400000)==0;
> The above ones are the same in any DSK example, which is
> making me confused why my flash is erased.

Does your board design contain the same CPLD and switches as the DSK? My guess is
not. For example, in which EMIF space is the IO_PORT address on the DSK board? Does
that correspond to the Flash addr space on your board?

In general, using "DSK specific code" on your board may cause issues if there are
even slight differences.

-Jeff
> > I have successfully implemented a second-level DSP/BIOS bootloader on C6711D and my application works well. The problem is that the first sector of the flash is erased after some time. Only the first value is random while the rest are FF. This time may vary from days to months.
> > The DSP relies on the IPU/IPD for its default boot mode – 8 bit asynchronous flash.
> > I have observed (at the scope) 4 writing operations after the copy of the first 1k into the internal memory. These write operations occur 1 micro second after the copy of the bootloader (the DSP clock frequency is 50 MHz). Therefore they are surely not as a result from the bootloader instructions. The strange part is that these writing operations seems to be at random space. I have observed them many times after the reset and transferring the bootloader into the internal ram. Therefore I am ordering them with the bigger probability to occur at the top:
> > 4 writing operations at CE0 space - external RAM
> > 4 writing operations at CE3 space – not used in my board
> > no writing operations – which is correct
> >
> > I did not observed writing operations at CE1 and CE2, but I suppose that the corrupted flash is because of writing at CE1.
> > During these write operations the addresses, data and CE signals are not changing. However they are not the same after each reset. Most often EA4 is varying and some others too.
> > Do you have any idea why the DSP performs these 4 writes? I did not find any description of such a behavior in its documentation! At least give me some suggestions to clear this problem.
> >
> >Thank you in advance!

Richard-

> I might wonder about that line of code:
>
> Proto_CPLD_Input_SW1=(io_port_values&0x0400000)==0
>
> According to my understanding, the '=' gets performed before the '=='
> so, this assignment is performed first:
> Proto_CPLD_Input_SW1=(io_port_values&0x0400000)
>
> then this comparison:
> (io_port_values&0x0400000)==0
>
> May I suggest the following change:
> Proto_CPLD_Input_SW1 = ( (io_port_values&0x0400000) == 0 );
>
> then Proto_CPLD_Input_SW1 is set to 'true' or 'false'
> I.E. if the bit is '1' then Proto_CPLD_Input_SW1 is set 'false;
> otherwise Proto_CPLD_Input_SW1 is set 'true'
>
> And while any value, in a variable, other than '0' will be
> treated as 'true', I would suggest being explicit in your
> assignments
>
> Also,
>
> It takes an extended amount of time to erase a section of flash. (up to 11 seconds on some DSPs.)
> So the executed line(s) that created the problem were executed long before this 'if' statement.

Flash sector erase time is highly device-dependent, including how much data in the
sector actually needs to be erased. It's conceivable that Dragomir's Flash gets a
sector erased very quick... but it's harder to see how the perfect combination of
commands and command sequence can be emitted by a bit of errant DSP code. Did I say
logic analyzer :-)

-Jeff

> ---------- Original Message -----------
> From: d...@yahoo.com
> To: c...
> Sent: Thu, 19 Jun 2008 08:15:29 -0400
> Subject: [c6x] Re: Undesired flash writing after bootloading
>
> > Hi,
> > Thank you for the advices! With your help I have identified the piece of code that is
> > causing the problem. I am still not sure if it is a hardware or software problem, but it
> > is provoked by the software. I have found the piece of code by inserting endless loops in
> > the software and then observing the result. The flash got corrupted after this line: if
> > (Proto_CPLD_Input_SW1==1) Unfortunately I can not understand why this comparison erases
> > the flash. The CCS is not showing me any code, after this command line, when I switch on
> > “view mixed source/asm”. The integer variable Proto_CPLD_Input_SW1 initializes its
> > value by the following commands: io_port_values=*(unsigned volatile int *)IO_PORT;
> > Proto_CPLD_Input_SW1=(io_port_values&0x0400000)==0; The above ones are the same in any
> > DSK example, which is making me confused why my flash is erased. I will be grateful if
> > you give me any ideas?
> >
> > Thank you in advance
> > Drago
> >
> > Hi,
> > > I have successfully implemented a second-level DSP/BIOS bootloader on C6711D and my application
> works well. The problem is that the first sector of the flash is erased after some time. Only the
> first value is random while the rest are FF. This time may vary from days to months.
> > > The DSP relies on the IPU/IPD for its default boot mode – 8 bit asynchronous flash.
> > > I have observed (at the scope) 4 writing operations after the copy of the first 1k into the
> internal memory. These write operations occur 1 micro second after the copy of the bootloader (the
> DSP clock frequency is 50 MHz). Therefore they are surely not as a result from the bootloader
> instructions. The strange part is that these writing operations seems to be at random space. I have
> observed them many times after the reset and transferring the bootloader into the internal ram.
> Therefore I am ordering them with the bigger probability to occur at the top:
> > > 4 writing operations at CE0 space - external RAM
> > > 4 writing operations at CE3 space – not used in my board
> > > no writing operations – which is correct
> > >
> > > I did not observed writing operations at CE1 and CE2, but I suppose that the corrupted flash is
> because of writing at CE1.
> > > During these write operations the addresses, data and CE signals are not changing. However they
> are not the same after each reset. Most often EA4 is varying and some others too.
> > > Do you have any idea why the DSP performs these 4 writes? I did not find any description of such
> a behavior in its documentation! At least give me some suggestions to clear this problem.
> > >
> > >Thank you in advance!
> > >
> > > Dragomir Nikolov

dragon,

I might wonder about that line of code:

Proto_CPLD_Input_SW1=(io_port_values&0x0400000)==0

According to my understanding, the '=' gets performed before the '=='
so, this assignment is performed first:
Proto_CPLD_Input_SW1=(io_port_values&0x0400000)

then this comparison:
(io_port_values&0x0400000)==0

May I suggest the following change:
Proto_CPLD_Input_SW1 = ( (io_port_values&0x0400000) == 0 );

then Proto_CPLD_Input_SW1 is set to 'true' or 'false'
I.E. if the bit is '1' then Proto_CPLD_Input_SW1 is set 'false;
otherwise Proto_CPLD_Input_SW1 is set 'true'
And while any value, in a variable, other than '0' will be treated as 'true', I would
suggest being explicit in your assignments
Also,

It takes an extended amount of time to erase a section of flash. (up to 11 seconds on some DSPs.)
So the executed line(s) that created the problem were executed long before this 'if' statement.

R. Williams

---------- Original Message -----------
From: d...@yahoo.com
To: c...
Sent: Thu, 19 Jun 2008 08:15:29 -0400
Subject: [c6x] Re: Undesired flash writing after bootloading

> Hi,
> Thank you for the advices! With your help I have identified the piece of code that is
> causing the problem. I am still not sure if it is a hardware or software problem, but it
> is provoked by the software. I have found the piece of code by inserting endless loops in
> the software and then observing the result. The flash got corrupted after this line: if
> (Proto_CPLD_Input_SW1==1) Unfortunately I can not understand why this comparison erases
> the flash. The CCS is not showing me any code, after this command line, when I switch on
> “view mixed source/asm”. The integer variable Proto_CPLD_Input_SW1 initializes its
> value by the following commands: io_port_values=*(unsigned volatile int *)IO_PORT;
> Proto_CPLD_Input_SW1=(io_port_values&0x0400000)==0; The above ones are the same in any
> DSK example, which is making me confused why my flash is erased. I will be grateful if
> you give me any ideas?
>
> Thank you in advance
> Drago
>
> Hi,
> > I have successfully implemented a second-level DSP/BIOS bootloader on C6711D and my application
works well. The problem is that the first sector of the flash is erased after some time. Only the
first value is random while the rest are FF. This time may vary from days to months.
> > The DSP relies on the IPU/IPD for its default boot mode – 8 bit asynchronous flash.
> > I have observed (at the scope) 4 writing operations after the copy of the first 1k into the
internal memory. These write operations occur 1 micro second after the copy of the bootloader (the
DSP clock frequency is 50 MHz). Therefore they are surely not as a result from the bootloader
instructions. The strange part is that these writing operations seems to be at random space. I have
observed them many times after the reset and transferring the bootloader into the internal ram.
Therefore I am ordering them with the bigger probability to occur at the top:
> > 4 writing operations at CE0 space - external RAM
> > 4 writing operations at CE3 space – not used in my board
> > no writing operations – which is correct
> >
> > I did not observed writing operations at CE1 and CE2, but I suppose that the corrupted flash is
because of writing at CE1.
> > During these write operations the addresses, data and CE signals are not changing. However they
are not the same after each reset. Most often EA4 is varying and some others too.
> > Do you have any idea why the DSP performs these 4 writes? I did not find any description of such
a behavior in its documentation! At least give me some suggestions to clear this problem.
> >
> >Thank you in advance!
> >
> > Dragomir Nikolov

Drago,

On 6/19/08, d...@yahoo.com wrote:
> Hi,
> Thank you for the advices! With your help I have identified the piece of code that is causing the problem. I am still not sure if it is a hardware or software problem, but it is provoked by the software. I have found the piece of code by inserting endless loops in the software and then observing the result.
> The flash got corrupted after this line:
> if (Proto_CPLD_Input_SW1==1)
> Unfortunately I can not understand why this comparison erases the flash. The CCS is not showing me any code, after this command line, when I switch on "view mixed source/asm".
> The integer variable Proto_CPLD_Input_SW1 initializes its value by the following commands:
> io_port_values=*(unsigned volatile int *)IO_PORT;
> Proto_CPLD_Input_SW1=(io_port_values&0x0400000)==0;
> The above ones are the same in any DSK example, which is making me confused why my flash is erased.
> I will be grateful if you give me any ideas?

Do you remember your original assumption?? [I am not sure exactly what
was in your mind]
One of the greatest difficulties when troubleshooting hard problems is
that we make assumptions and assume them as facts without realizing
it.
Also, never assume that something works just because it came from an example.

I assume that 'SW1' is not important for testing/debugging at this
point. Comment out the I/O lines of code and replace it with hardcoded
values that you expect.

Can you control the problem by switching between 'hard coded' and 'I/O
determined' SW values?? If yes, your FPGA may be 'helping you more
than you realize' :-)

mikedunn
>
> Thank you in advance
> Drago
> Hi,
> > I have successfully implemented a second-level DSP/BIOS bootloader on C6711D and my application works well. The problem is that the first sector of the flash is erased after some time. Only the first value is random while the rest are FF. This time may vary from days to months.
> > The DSP relies on the IPU/IPD for its default boot mode 8 bit asynchronous flash.
> > I have observed (at the scope) 4 writing operations after the copy of the first 1k into the internal memory. These write operations occur 1 micro second after the copy of the bootloader (the DSP clock frequency is 50 MHz). Therefore they are surely not as a result from the bootloader instructions. The strange part is that these writing operations seems to be at random space. I have observed them many times after the reset and transferring the bootloader into the internal ram. Therefore I am ordering them with the bigger probability to occur at the top:
> > 4 writing operations at CE0 space - external RAM
> > 4 writing operations at CE3 space not used in my board
> > no writing operations which is correct
> >
> > I did not observed writing operations at CE1 and CE2, but I suppose that the corrupted flash is because of writing at CE1.
> > During these write operations the addresses, data and CE signals are not changing. However they are not the same after each reset. Most often EA4 is varying and some others too.
> > Do you have any idea why the DSP performs these 4 writes? I did not find any description of such a behavior in its documentation! At least give me some suggestions to clear this problem.
> >
> >Thank you in advance!
> >
> > Dragomir Nikolov
>
> >
> >
>
>
>
>
>
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php

Hi,
Thank you for the advices! With your help I have identified the piece of code that is causing the problem. I am still not sure if it is a hardware or software problem, but it is provoked by the software. I have found the piece of code by inserting endless loops in the software and then observing the result.
The flash got corrupted after this line:
if (Proto_CPLD_Input_SW1==1)
Unfortunately I can not understand why this comparison erases the flash. The CCS is not showing me any code, after this command line, when I switch on “view mixed source/asm”.
The integer variable Proto_CPLD_Input_SW1 initializes its value by the following commands:
io_port_values=*(unsigned volatile int *)IO_PORT;
Proto_CPLD_Input_SW1=(io_port_values&0x0400000)==0;
The above ones are the same in any DSK example, which is making me confused why my flash is erased.
I will be grateful if you give me any ideas?

Thank you in advance
Drago
Hi,
> I have successfully implemented a second-level DSP/BIOS bootloader on C6711D and my application works well. The problem is that the first sector of the flash is erased after some time. Only the first value is random while the rest are FF. This time may vary from days to months.
> The DSP relies on the IPU/IPD for its default boot mode – 8 bit asynchronous flash.
> I have observed (at the scope) 4 writing operations after the copy of the first 1k into the internal memory. These write operations occur 1 micro second after the copy of the bootloader (the DSP clock frequency is 50 MHz). Therefore they are surely not as a result from the bootloader instructions. The strange part is that these writing operations seems to be at random space. I have observed them many times after the reset and transferring the bootloader into the internal ram. Therefore I am ordering them with the bigger probability to occur at the top:
> 4 writing operations at CE0 space - external RAM
> 4 writing operations at CE3 space – not used in my board
> no writing operations – which is correct
>
> I did not observed writing operations at CE1 and CE2, but I suppose that the corrupted flash is because of writing at CE1.
> During these write operations the addresses, data and CE signals are not changing. However they are not the same after each reset. Most often EA4 is varying and some others too.
> Do you have any idea why the DSP performs these 4 writes? I did not find any description of such a behavior in its documentation! At least give me some suggestions to clear this problem.
>
>Thank you in advance!
>
> Dragomir Nikolov

Dragomir-

> I think I was not clear enough. The writings do not happen all the time
> (after each reset of the DSP). They occur randomly and in random space,
> however more often in CE0. These writings are caused by the DSP and
> they do not depend of the bootloader program. They persist even if the
> flash memory chip is removed from the board.
> That is why I am asking for some help in order to explain how the DSP
> provokes this problem.

You say "randomly" -- how often? For what (approx) percentage of reset/boot do the
write strobes occur?

> Maybe it is some strange boot configuration or DSP option?

Maybe, but more likely it's your code, something like an uninitialized pointer, or
pipeline violation.

> I will be thankful for any advice!

Use CCS + emulator, allow your code to run until after the 1k boot copy (Mike's
suggestion is a sw breakpoint), then single-step your code until you see a write
strobe on the scope. Then you know exactly what code committed the crime.

Yes that's tedious and could take a while, but you won't debug this by guessing at
it.

-Jeff

> Hi,
> > I have successfully implemented a second-level DSP/BIOS bootloader on C6711D and my application works well. The problem is that the first sector of the flash is erased after some time. Only the first value is random while the rest are FF. This time may vary from days to months.
> > The DSP relies on the IPU/IPD for its default boot mode – 8 bit asynchronous flash.
> > I have observed (at the scope) 4 writing operations after the copy of the first 1k into the internal memory. These write operations occur 1 micro second after the copy of the bootloader (the DSP clock frequency is 50 MHz). Therefore they are surely not as a result from the bootloader instructions. The strange part is that these writing operations seems to be at random space. I have observed them many times after the reset and transferring the bootloader into the internal ram. Therefore I am ordering them with the bigger probability to occur at the top:
> > 4 writing operations at CE0 space - external RAM
> > 4 writing operations at CE3 space – not used in my board
> > no writing operations – which is correct
> >
> > I did not observed writing operations at CE1 and CE2, but I suppose that the corrupted flash is because of writing at CE1.
> > During these write operations the addresses, data and CE signals are not changing. However they are not the same after each reset. Most often EA4 is varying and some others too.
> > Do you have any idea why the DSP performs these 4 writes? I did not find any description of such a behavior in its documentation! At least give me some suggestions to clear this problem.
> >
> >Thank you in advance!

Dragomir,

On 6/17/08, d...@yahoo.com wrote:
> I think I was not clear enough. The writings do not happen all the time (after each reset of the DSP). They occur randomly and in random space, however more often in CE0. These writings are caused by the DSP and they do not depend of the bootloader program. They persist even if the flash memory chip is removed from the board.
> That is why I am asking for some help in order to explain how the DSP provokes this problem. Maybe it is some strange boot configuration or DSP option?
> I will be thankful for any advice!

First I will start with a fact [as I understand it]:

1. Any time that you reset a 6711 device [EXCEPT in HPI boot mode],
the DSP will 'fetch and try to execute something'. This will happen
even if there are no external memory devices connected.
2. Try your test with the device in HPI boot mode to ensure that the
signals are not occuring during reset.
3. Embed a software breakpoint in flash [ asm( .word 0x10000000); ]
just before you branch to internal RAM. Perform resets and run to
breakpoint. Repeat and observe your problem signals. *Do NOT use a GEL
file*
NOTE: You must have an emulator connected for the DSP to recognize the
sw bp. You may be able to issue 'run free' from CCS and keep reseting
the device.
4. Have you seen strobes yet??
5. If no, remove the embedded sw bp.
6. You will probably have to use AET to catch your error. Let me know
if you get here.

FYI - I have worked on a few 6211/6711/6713 boards - some of which
have been reset many thousands of times and others that have run for
extended periods of time. I have never seen a Flash corruption
problem that was not due to defective hardware or software.

7. Have you monitored your power supply with a scope??

mikedunn
>
> Dragomir Nikolov
> Hi,
> > I have successfully implemented a second-level DSP/BIOS bootloader on C6711D and my application works well. The problem is that the first sector of the flash is erased after some time. Only the first value is random while the rest are FF. This time may vary from days to months.
> > The DSP relies on the IPU/IPD for its default boot mode 8 bit asynchronous flash.
> > I have observed (at the scope) 4 writing operations after the copy of the first 1k into the internal memory. These write operations occur 1 micro second after the copy of the bootloader (the DSP clock frequency is 50 MHz). Therefore they are surely not as a result from the bootloader instructions. The strange part is that these writing operations seems to be at random space. I have observed them many times after the reset and transferring the bootloader into the internal ram. Therefore I am ordering them with the bigger probability to occur at the top:
> > 4 writing operations at CE0 space - external RAM
> > 4 writing operations at CE3 space not used in my board
> > no writing operations which is correct
> >
> > I did not observed writing operations at CE1 and CE2, but I suppose that the corrupted flash is because of writing at CE1.
> > During these write operations the addresses, data and CE signals are not changing. However they are not the same after each reset. Most often EA4 is varying and some others too.
> > Do you have any idea why the DSP performs these 4 writes? I did not find any description of such a behavior in its documentation! At least give me some suggestions to clear this problem.
> >
> >Thank you in advance!
> >
> > Dragomir Nikolov
>
>
>
>
>
>
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php

Hi,

do you have any code in your application that is able to write/erase the
flash? Maybe something run berserk and this code is executed.

How do you program your flash? In circuit or by programmer? Maybe you
can use protection features of you flash.

HTH

Gustl
d...@yahoo.com schrieb:
> I think I was not clear enough. The writings do not happen all the
> time (after each reset of the DSP). They occur randomly and in random
> space, however more often in CE0. These writings are caused by the
> DSP and they do not depend of the bootloader program. They persist
> even if the flash memory chip is removed from the board. That is why
> I am asking for some help in order to explain how the DSP provokes
> this problem. Maybe it is some strange boot configuration or DSP
> option? I will be thankful for any advice!
>
> Dragomir Nikolov
> Hi,
>> I have successfully implemented a second-level DSP/BIOS bootloader
>> on C6711D and my application works well. The problem is that the
>> first sector of the flash is erased after some time. Only the first
>> value is random while the rest are FF. This time may vary from days
>> to months. The DSP relies on the IPU/IPD for its default boot mode
>> ? 8 bit asynchronous flash. I have observed (at the scope) 4
>> writing operations after the copy of the first 1k into the internal
>> memory. These write operations occur 1 micro second after the copy
>> of the bootloader (the DSP clock frequency is 50 MHz). Therefore
>> they are surely not as a result from the bootloader instructions.
>> The strange part is that these writing operations seems to be at
>> random space. I have observed them many times after the reset and
>> transferring the bootloader into the internal ram. Therefore I am
>> ordering them with the bigger probability to occur at the top: 4
>> writing operations at CE0 space - external RAM 4 writing
>> operations at CE3 space ? not used in my board no writing
>> operations ? which is correct I did not observed writing
>> operations at CE1 and CE2, but I suppose that the corrupted flash
>> is because of writing at CE1. During these write operations the
>> addresses, data and CE signals are not changing. However they are
>> not the same after each reset. Most often EA4 is varying and some
>> others too. Do you have any idea why the DSP performs these 4
>> writes? I did not find any description of such a behavior in its
>> documentation! At least give me some suggestions to clear this
>> problem.
>>
>> Thank you in advance!
>>
>> Dragomir Nikolov
>

I think I was not clear enough. The writings do not happen all the time (after each reset of the DSP). They occur randomly and in random space, however more often in CE0. These writings are caused by the DSP and they do not depend of the bootloader program. They persist even if the flash memory chip is removed from the board.
That is why I am asking for some help in order to explain how the DSP provokes this problem. Maybe it is some strange boot configuration or DSP option?
I will be thankful for any advice!

Dragomir Nikolov
Hi,
> I have successfully implemented a second-level DSP/BIOS bootloader on C6711D and my application works well. The problem is that the first sector of the flash is erased after some time. Only the first value is random while the rest are FF. This time may vary from days to months.
> The DSP relies on the IPU/IPD for its default boot mode – 8 bit asynchronous flash.
> I have observed (at the scope) 4 writing operations after the copy of the first 1k into the internal memory. These write operations occur 1 micro second after the copy of the bootloader (the DSP clock frequency is 50 MHz). Therefore they are surely not as a result from the bootloader instructions. The strange part is that these writing operations seems to be at random space. I have observed them many times after the reset and transferring the bootloader into the internal ram. Therefore I am ordering them with the bigger probability to occur at the top:
> 4 writing operations at CE0 space - external RAM
> 4 writing operations at CE3 space – not used in my board
> no writing operations – which is correct
>
> I did not observed writing operations at CE1 and CE2, but I suppose that the corrupted flash is because of writing at CE1.
> During these write operations the addresses, data and CE signals are not changing. However they are not the same after each reset. Most often EA4 is varying and some others too.
> Do you have any idea why the DSP performs these 4 writes? I did not find any description of such a behavior in its documentation! At least give me some suggestions to clear this problem.
>
>Thank you in advance!
>
> Dragomir Nikolov

Dragomir-

> I have successfully implemented a second-level DSP/BIOS bootloader
> on C6711D and my application works well. The problem is that the first
> sector of the flash is erased after some time. Only the first value is
> random while the rest are FF. This time may vary from days to months.
> The DSP relies on the IPU/IPD for its default boot mode – 8
> bit asynchronous flash.
> I have observed (at the scope) 4 writing operations after the
> copy of the first 1k into the internal memory. These write operations
> occur 1 micro second after the copy of the bootloader (the DSP clock
> frequency is 50 MHz). Therefore they are surely not as a result from
> the bootloader instructions. The strange part is that these writing
> operations seems to be at random space. I have observed them many times
> after the reset and transferring the bootloader into the internal ram.
> Therefore I am ordering them with the bigger probability to occur at
> the top:
> 4 writing operations at CE0 space - external RAM
> 4 writing operations at CE3 space – not used in my board
> no writing operations – which is correct
>
> I did not observed writing operations at CE1 and CE2, but I
> suppose that the corrupted flash is because of writing at CE1.
> During these write operations the addresses, data and CE
> signals are not changing. However they are not the same after each
> reset. Most often EA4 is varying and some others too.
> Do you have any idea why the DSP performs these 4 writes?
> I did not find any description of such a behavior in its
> documentation! At least give me some suggestions to clear this
> problem.

Since you say this always happens (not intermittent), and you you know it's about 1
usec after the bootloader 1k copy, then why don't you just use CCS + emulator and
single-step your code until you see a write strobe on the scope? Where is the code
when it happens?

-Jeff